WO2010028589A1 - 业务推送协商方法及装置、推送业务系统 - Google Patents

业务推送协商方法及装置、推送业务系统 Download PDF

Info

Publication number
WO2010028589A1
WO2010028589A1 PCT/CN2009/073811 CN2009073811W WO2010028589A1 WO 2010028589 A1 WO2010028589 A1 WO 2010028589A1 CN 2009073811 W CN2009073811 W CN 2009073811W WO 2010028589 A1 WO2010028589 A1 WO 2010028589A1
Authority
WO
WIPO (PCT)
Prior art keywords
push
push service
information
service
identifier
Prior art date
Application number
PCT/CN2009/073811
Other languages
English (en)
French (fr)
Inventor
李幼颖
王丰
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2010028589A1 publication Critical patent/WO2010028589A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services

Definitions

  • the present invention relates to the field of network service push, and in particular to a service push negotiation method and device, and a push service system. Background technique
  • IPTV Internet Protocol Television
  • IMS Multimedia Subsystem
  • QoS Quality of Service
  • IMS-based IMS IMS Based IPTV
  • Service/content providers can provide users with live broadcast (BC) and content on demand (CoD) through IMS Based IPTV network.
  • BC live broadcast
  • CoD content on demand
  • Basic IPTV services which are usually initiated by users and complete related media negotiation and session establishment; as shown in Figure 1, the TISPAN IMS Based IPTV network architecture, the architecture includes:
  • Service Selection Function (SSF) entity and Service Discovery Function (SDF) entity Provides service navigation functions, including service discovery information and service selection information
  • Service Control Function (SCF) entity Provides service authorization and session management functions for basic services. Currently, it includes service control functions for basic services such as BC and CoD.
  • MF Media Function Entity
  • the user can pre-register the service in the network, and when a program of a certain channel starts to be broadcasted. The program that the user is watching is switched to the channel; or the user registers the type of the program that he is interested in, and when the related program is deployed in the network, the network side actively pushes the content to the user terminal, and other possibilities are Demand, the network requires the network to actively push some content to the user, and the current network does not provide a solution.
  • the technical problem to be solved by the present invention is to provide a service push negotiation method and device, and a push service system, which can initiate a session to the user to push the required content through the network side, and trigger the push service logic by pushing the service information, and negotiate to complete the push.
  • Business logic can initiate a session to the user to push the required content through the network side, and trigger the push service logic by pushing the service information, and negotiate to complete the push.
  • the embodiment of the present invention provides a service push negotiation method, where the method is applied to a network television based on a multimedia subsystem IMS Based IPTV network, and the method includes:
  • the embodiment of the present invention further provides a service push negotiation device, where the device is applied to a network television based on a multimedia subsystem IMS Based IPTV network, and the device includes: a receiving unit, configured to receive push service information, where the push service information carries a push service identifier;
  • a parsing unit configured to parse the push service information received by the receiving unit
  • a sending unit configured to trigger a push service logic according to the push service information, and send a push service request, where the push service request carries a push content identifier
  • the negotiating unit is configured to negotiate to complete the push service logic.
  • the embodiment of the present invention further provides a service pushing system, where the system is applied to a network television based on a multimedia subsystem IMS Based IPTV network, where the system includes an application function entity, a service control function entity, and a receiving function entity;
  • the application function entity is configured to send push service information to the service control function entity, where the push service information carries a push service identifier;
  • the service control function entity is configured to receive the push service information sent by the application function entity; and parse the received push service information; and trigger the push service logic to send a push service request according to the push service information, where Pushing the service request includes pushing the content identifier; and completing the push service logic by negotiating with the receiving function entity;
  • the receiving function entity is configured to receive a push service request sent by the service control function entity; and complete the push service logic by negotiating with the service control function entity.
  • FIG. 1 is a schematic structural diagram of an existing TISPAN IMS Based IPTV network architecture
  • FIG. 2 is a schematic flowchart of a service push negotiation method according to an embodiment of the present invention
  • FIG. 3 is a schematic structural diagram of a service push negotiation apparatus according to an embodiment of the present invention
  • 4 is a schematic structural diagram of a service push system according to an embodiment of the present invention
  • FIG. 5 is a schematic diagram of a specific embodiment 1 of a service push negotiation method according to the present invention
  • FIG. 6 is a schematic diagram of a second embodiment of a service push negotiation method according to the present invention
  • FIG. 7 is a specific embodiment of a service push negotiation method according to the present invention
  • FIG. 2 is a schematic flowchart of a service push negotiation method according to an embodiment of the present invention. The method is applied to an IMS Based IPTV network. As shown in FIG. 2, the method includes:
  • the push service information is received, where the push service information carries a push service identifier.
  • the push service identifier may include channel information, program information, or content information.
  • the push service information may further include any one or more of the following information: Receiving user information of the push service;
  • the push service information can be based on the Session Description Protocol (Session Description Protocol,
  • Push service information can also be carried by the Session Initiation Protocol (SIP) message body, such as MESSAGE, SUBSCRIBE/NOTIFY, INVITE, INFO, etc., or Hypertext Transfer Protocol (HTTP), etc.
  • SIP Session Initiation Protocol
  • MESSAGE SUBSCRIBE/NOTIFY
  • INVITE INVITE
  • INFO INFO
  • HTTP Hypertext Transfer Protocol
  • the push service information needs to include the push service identifier indicating that the information is the push service information; the push service identifier may also be carried by the SIP message body or other protocol message body such as HTTP, for example, may be defined by a newly defined message entity type (Content-Type) Push the business identity, such as the newly defined message entity type: Application/iptv-push+xml;
  • the push service identifier can also be defined by XML, as shown in the following XML definition:
  • ⁇ !-SessionPush type definition can contain attribute definitions for push business information ⁇
  • the media feature tag can be carried in the SIP header field.
  • the SIP header field can be a new header field or an existing header field such as Accept-Contact. For example:
  • P-Preferred-Service urn:xxx:iptv:sessionpush.
  • 202 into one includes:
  • the push service information Determining, according to the push service identifier, the push service information as a push service request; and obtaining any one or more of the push service receiving user identification information, the push service push content identifier, and the push service push time information.
  • the push service identifier is determined to be a push service request by using a push service identifier; the push service information may be determined and obtained through a Content-Type, for example, detecting a Content-Type as "application/iptv-push+xml";
  • the push service information can be parsed according to the XML definition, and one or more of the following information can be obtained:
  • the push service receives user identification information
  • a push service request is initiated by generating a SIP request, where the SIP Request-URI in the push service request is set as a push service receiving user identifier, and when the push service receiving device is a user IPTV UE, the identifier may be an IMS public user identifier.
  • IMS Public User Identity IMS Public User Identity
  • the service push request needs to carry the push service push content identifier, which can be carried by the user part in the SIP identifier carried by the SIP From header field;
  • the push content identifier may also be carried by the SIP message body.
  • the push content identifier may be defined and carried by the xml, for example, by using the IPTV PushActionData defined in the foregoing 201;
  • the push service request may carry the push service identifier, and the push service identifier may be carried in the SIP header field, for example, P-Preferred-Service: urn:xxx:iptv:sessionpush;
  • the push service request may further carry any one or any combination of the information included in the push service information, in addition to the push service identifier; and the push service request may further carry the information included in the push service information.
  • Any one or any combination of the push service information may be carried in the SIP header field or the SIP message body.
  • the transparent information can be transparently transmitted through IPTVPushActionData.
  • 203 includes:
  • the above push service request is a SIP request, which may be a message such as INVITE, MESSAGE, REFER.
  • the push information to be received may be determined according to the push content identifier
  • the push content identifier may be obtained from the SIP identity user part carried by the SIP From header field; or obtained from the message body;
  • the local push service logic can also be executed according to the push service identifier
  • the push service identifier can be obtained from the SIP header field, for example
  • P-Preferred-Service urn:xxx:iptv:sessionpush; or,
  • the push service identifier is obtained by parsing the SIP message body, for example
  • the push service logic is triggered to push the push service logic, and the push service logic is negotiated.
  • the network side can actively initiate a session to push the required content to the user.
  • the application deployment can be effectively improved, and the complexity of the network can be simplified.
  • FIG. 3 is a schematic structural diagram of a service push negotiation apparatus according to an embodiment of the present invention.
  • the apparatus is applied to an IMS Based IPTV network. As shown in FIG. 3, the apparatus includes:
  • the receiving unit 10 is configured to receive push service information, where the push service information carries a push service identifier;
  • the parsing unit 11 is configured to parse the push service information received by the receiving unit 10;
  • the sending unit 12 is configured to trigger a push service logic according to the push service information, and send a push service request, where the push service request carries a push content identifier ;
  • the negotiating unit 13 is configured to negotiate to complete the push service logic.
  • parsing unit 11 includes:
  • the determining unit 110 is configured to determine, according to the push service identifier, the push service information as a push service request;
  • the obtaining unit 111 is configured to obtain any one or more of three types: the push service receiving user identification information, the push service push content identifier, and the push service push time information.
  • the push service identifier includes the channel information, the program information, or the content information.
  • the push service information described in the device embodiment may further include any one or more of the following information:
  • the service push negotiation device of this embodiment is a service control unit, and the unit can be implemented in a service control function entity in the IPTV network.
  • FIG. 4 is a schematic structural diagram of a service push system according to an embodiment of the present invention.
  • the system is applied to an IMS Based IPTV network.
  • the system includes an application function entity 1, a service control function entity 2, and a receiving function entity 3;
  • the application function entity 1 is configured to send the push service information to the service control function entity 2, where the push service information carries the push service identifier; where the application function entity 1 can be embodied as a push service trigger unit in the specific implementation,
  • the service triggering unit can be implemented on the user IPTV terminal, or implemented on other functional entities, such as a background configuration function, an independent enhanced function, and the like.
  • the service control function entity 2 is configured to receive the push service information sent by the application function entity 1 and parse the received push service information; and trigger the push service logic to send a push service request according to the push service information,
  • the push service request includes a push content identifier; and the push function logic 3 is negotiated with the receiving function entity 3;
  • the service control function entity 2 can be embodied as a service control unit in a specific implementation, and the service control unit can be in the IPTV network.
  • the service control function (SCF) entity is implemented, and its functional structure is as described in the service push negotiation device of FIG.
  • the receiving function entity 3 is configured to receive a push service request generated by the service control function entity 2 according to the push service information, where the push service request carries a push content identifier; and negotiate with the service control function entity 2 Complete the push business logic.
  • the receiving function here is real
  • the body 3 can be embodied as a push service receiving unit in a specific implementation, and is usually implemented in a user IPTV terminal.
  • the application function entity 1 and the service control function entity 2 may be separate functional entities, or may be combined into one functional entity; the application function entity 1 and the receiving function entity 3 may be separate functional entities, respectively. Combined into a functional entity.
  • the application function entity 1 and the receiving function entity 3 may be merged into one functional entity, or the application function entity 1 and the service control function entity 2 are merged into one functional entity to implement the application function entity 1.
  • the service control function entity 2 receives the function of the function entity 3 as a single entity.
  • the implementation of the system of the present invention triggers the push service logic by pushing the service information, and negotiates the completion of the push service logic; the network side can initiate the session to push the required content to the user; the general push function of the service can be implemented, followed by various specific Push business; can effectively improve the deployment of applications and simplify the complexity of the network.
  • FIG. 5 is a schematic diagram of a specific embodiment 1 of a service push negotiation method according to the present invention.
  • the application function entity push service triggering unit
  • the receiving function entity pumping service receiving unit
  • the service control function entity that is, the service control unit
  • the user determines the program information to be switched by browsing the program navigation information of the UE, and the UE generates a timing channel switching customization request according to the push service information format, that is, the push service request, including the user identifier to be pushed, the channel identifier, and the switching time information;
  • the SCF entity receives The user switches the customization request through the timing channel initiated by the UE, and triggers the push service logic when the condition is satisfied according to the user information, the program information, and the time information included in the customization request, and initiates a channel switching request to the designated user.
  • the method includes: 501.
  • the UE initiates a channel switching customization request by using a SIP message (SIP MESSAGE), where:
  • the Request-URI is the PSI identifier of the SCF.
  • the SIP MESSAGE message body includes channel switching information.
  • the UE generates channel switching information based on the push service information template, and includes push service information, where the push service information includes a push service identifier.
  • the core IMS (Core IMS) forwards the SIP MESSAGE to the SCF entity;
  • the SCF entity receives and parses the SIP MESSAGE, and the process includes:
  • IPTV ActionDataCommand element determining that the IPTV ActionDataCommand element is included in the xml, and the value field is "SessionPush" is determined to trigger the push service logic; Detecting and parsing the message body, and obtaining the push service information from the value range of the 'IPTVPushActionData' element in the xml;
  • the SCF entity may determine, according to the user identifier (UserList) and the content identifier (PushContentld) in the push service information, whether the user has the right to view the program;
  • the SCF entity determines to initiate to the user sip:user-a@iptv.com at 21:00.
  • the SCF entity determines that the user can complete the timed handover, and sends a success response message (200 OK message) to the UE.
  • the Core IMS forwards the success response message to the UE.
  • the SCF entity initiates a push service request according to the obtained push service information and the media parameter information.
  • the SIP INVITE where:
  • the Request-URI is a user identifier (UserList) obtained from the push service information
  • the From header field carries the channel identifier (PushContentld) to be switched from the push service description information, where is the SIP identifier, where the user part part carries the channel identifier, and the domain name part is the domain name of the SCF;
  • the P-Preferred-Service header field may carry the push service identifier urn:xxx:iptv.sessionpush, which is used to indicate to the user terminal that the currently initiated push service request is performed;
  • the content-type includes the application/sdp type, and initiates media negotiation through the SDP offer, and carries the media parameter information of the channel to be pushed;
  • the media parameter information of the to-be-pushed channel includes one or more kinds of information such as a multicast address, a media format, and a bandwidth.
  • the SCF entity can obtain the media parameter information in a plurality of manners, including: pre-configuring and saving related information on the SCF entity;
  • the SCF entity obtains media parameter information from a functional entity that stores media parameter information by using a SIP or a non-SIP request according to the channel identifier.
  • the Core IMS forwards the push service request to the UE.
  • the UE parses the received push service request, obtains channel information to be pushed, and media parameter information, and responds by sending a 200 OK message.
  • the UE may present relevant information to the user through the UE local application based on the push service identifier, the channel information, etc., and provide the user with a choice, for example, whether to switch to the channel, the user may make a selection through the remote controller, and the UE responds based on the user's selection.
  • the UE then initiates a successful response when the user chooses to agree to the handover;
  • the Core IMS forwards the 200 OK message to the SCF entity;
  • the SCF entity receives the 200 OK message sent by the UE, and completes the session establishment.
  • the UE receives the media stream, and the UE joins the multicast group according to the multicast address obtained in the session negotiation to receive the media stream, and completes channel switching.
  • the service control function entity provides a standard interface, and pushes the service information to trigger the push service logic to complete the push service.
  • the embodiment of the invention provides a method for pushing a channel custom switching service, and each application function only needs to complete corresponding application logic management, and does not need to repeatedly implement functions such as session negotiation and media negotiation, and can effectively improve new application functions.
  • the deployment efficiency simplifying the complexity of the network.
  • FIG. 6 is a schematic diagram of a second embodiment of a service push negotiation method according to the present invention.
  • the application function entity (push service triggering unit) in the embodiment is implemented on an advertisement function (ADF) entity, and the receiving function entity (push service receiving unit) is implemented on the UE, and the service control function entity (service control unit) Implemented on the SCF entity.
  • the ADF entity here may be a background configuration function entity or an application function entity.
  • the advertisement media is provided by a media function (MF), and may be provided by other functional entities in actual deployment, for example, directly
  • the advertising media is provided by the ADF entity, and may also be provided by other entities to the MF, and then forwarded by the MF to the UE; these situations are related to the specific advertising business.
  • the method includes:
  • the advertisement time in the BC program arrives, the advertisement server triggers the business logic, and provides the personalized advertisement to the user through the unicast mode, and the advertisement server generates the push advertisement information according to the push service information template, which includes the user information to be pushed, to be pushed. Advertising information, etc.; the advertisement server sends push service information to the SCF entity through SIP MESSAGE, where:
  • the Request-URI is a SIP identifier of the SCF entity, and is used to route the SIP message to the SCF, which may be a PSI;
  • the P-Preferred-Service header field contains a push service tag.
  • the SIP MESSAGE message body contains the service information to be pushed
  • the MESSAGE message body may also carry the media parameter information of the advertisement, and the media parameter is usually carried by the SDP;
  • SIP messages carry multiple types of message bodies. Considering that Content-Type uses the multipart/mixed type, push service information can be defined together by SDP and XML.
  • P-Preferred- Service urn:xxx:iptv.sessionpush
  • the SCF entity receives and parses the SIP MESSAGE, and sends a success response message to the ADF entity, including:
  • Detecting the SIP message header field contains "P-Preferred-Service: urn:xxx:iptv.sessionpush", which is confirmed as a push service message;
  • the message body is detected and parsed, and if application/sdp is included, the media parameter information of the push content is obtained.
  • the SCF entity triggers the push service logic according to the push service identifier (P-Preferred-Service: urn: xxx: iptv.sessionpush), and initiates a push service request, here is a SIP INVITE:
  • the push service request may also carry the push service identifier through the P-Preferred-Service header field, and indicate to the UE that the request is a push service request;
  • the SCF entity may also carry the media information of the advertisement content through the SIP INVITE message body.
  • the media parameter information is carried by the ADF entity through the SDP when initiating the push service request;
  • P-Preferred- Service urn:xxx:iptv.sessionpush
  • the Core IMS forwards the SIP request message to the UE.
  • the UE receives and parses the SIP request message.
  • the UE may trigger the push service logic to complete the processing related to the push service based on the identifier;
  • the UE parses the SIP identifier carried by the From header field, and obtains the push advertisement identifier from the user part, where Ad-1 is used;
  • the SIP request message carries the SDP media parameter information of the Ad-1 through the message body, the information needs to be obtained from the SDP;
  • the UE detects that the SCF entity does not initiate the SDP offer, so the SDP offer is initiated by the response message to perform media parameter negotiation; the SDP offer may be initiated by the 200 OK response;
  • the Core IMS forwards the 200 OK response message to the SCF entity.
  • the SCF entity receives and parses the 200 OK response message of the UE, and initiates a new INVITE request to the selected MF entity.
  • the media parameter information is obtained from the SDP offer carried in the response message.
  • the appropriate MF entity is selected according to the advertisement identifier, and the MF is selected.
  • the entity may refer to other information such as the location information of the UE to make a decision together;
  • the Request-URI is the SIP identifier of the selected MF entity
  • the SIP identifier of the To header field carrying the requested advertisement content may be composed of two parts, wherein the user part carries the advertisement content identifier, where is Ad-1, and the domain name part is the identifier of the MF entity; the P-Preferred-Service header field may be adopted. Carrying a push service identifier, indicating that the request is a push service request;
  • the proxy UE initiates media negotiation by using the message body to carry the SDP offer sent by the UE;
  • P-Preferred- Service urn:xxx:iptv.sessionpush 608, the MF entity receives and parses the SIP request message, completes the service processing, and returns a response, carrying the SDP answer; here, the response can be returned through 200 OK.
  • the SCF entity receives and parses the 200 OK message sent by the MF entity, and performs media negotiation with the UE. Terminates the response message of the MF entity, establishes a SIP session between the SCF entity and the MF entity, and obtains an SDP answer carried by the MF entity response. Media parameter in the response; responding to the UE's 200 OK response through the ACK message, and carrying the media parameters obtained from the MF entity through the SDP answer.
  • the Core IMS forwards an ACK message to the UE.
  • the UE receives and processes the ACK message, obtains the media parameter in the SDP answer, and responds to the acknowledgement by using the 200 OK message.
  • the Core IMS forwards the 200 OK message to the SCF entity.
  • the SCF entity receives and processes a 200 OK message, and establishes a SIP session between the UE and the SCF entity.
  • the UE establishes a media transmission and/or media control channel directly with the MF entity according to the negotiated media parameter.
  • the service control function entity provides a standard interface, and pushes the service information to trigger the push service logic to complete the push service.
  • the embodiment of the present invention provides a method for pushing an advertisement service, and each application function only needs to complete corresponding application logic management, and does not need to repeatedly implement functions such as session negotiation and media negotiation, thereby effectively improving deployment of new application functions. Efficiency, simplifying the complexity of the network.
  • FIG. 7 is a schematic diagram of a third embodiment of a service push negotiation method according to the present invention, where the user signs up
  • the content automatic download service is provided to the user, that is, the network side actively downloads the content to the user terminal without the user's participation.
  • the method includes:
  • the PAF entity triggers the Push CoD service logic according to the user subscription information, and initiates a push service request to the SCF entity to complete the push of the CoD content.
  • the push service request needs to carry a push service identifier, which is used to indicate that the SCF entity requests the push service, and also needs to carry the push service information, and the push service information is generated based on the interface template provided by the SCF entity, and includes the following information: The user identifier, the pushed CoD content identifier, and the media description information of the push CoD, wherein the media description information may include a pushed media protocol format, a media attribute, and the like.
  • the PAF entity can initiate a push service request to the SCF entity through the SIP MESSAGE, where:
  • the request-URI includes the SIP identifier of the SIP request to the SCF entity, which may be a PSI.
  • the SIP MESSAGE message body includes the information to be pushed, including the push service indication and the push service information.
  • the SCF entity receives the SIP MESSAGE, sends a successful response to the PAF entity, and parses the received SIP MESSAGE.
  • the SCF entity determines, according to the push service identifier in the push request, that the push service logic is triggered, and the push service information is obtained from the push request message body. This embodiment includes:
  • the xml is parsed, and the user information (UserList) to be pushed, the program information to be pushed (PushContentld), and the duration of the program to be pushed are obtained by the value range of the element IPTVPushActionData.
  • the SCF entity initiates a push service request to the MF entity, including:
  • the CoD identifier Content-1 is selected as the appropriate MF entity
  • the SCF entity initiates a push service request to the MF entity.
  • it is a SIP INVITE message, where:
  • the Request-URI is a SIP identifier that is routed to the selected MF entity, such as PSI;
  • the CoD SIP identifier carrying the request Push in the To header field may be composed of two parts, where the user part carries the CoD content identifier, where is Content-l, and the domain name part is the domain name of the MF entity;
  • the push service identifier can be carried in the P-Preferred-Service header field to indicate that the request is a push service request.
  • the MF entity receives and parses the SIP request message, including: If the request carries the push service tag, the P-Preferred-Service obtains the push service tag, and determines that the service request is a push service request, and may instruct the MF entity to process the push service logic;
  • the program identifier is obtained by parsing, in this embodiment, the program header identifier is obtained by parsing the To header field, where is Content-1, and a parameter such as a port number is allocated for transmitting the Content-1 content stream;
  • a 200 OK response message is generated, and the SDP offer is carried, carrying relevant media parameters, including media description information of the content-1, an IP address, a port number, and the like.
  • the SCF entity receives and parses the 200 OK message, including:
  • the SDP offer information is obtained from the 200 OK message, and the push service request is initiated according to the user identifier obtained in 702, where the request is a SIP INVITE, where:
  • the Request-URI is the SIP identifier of the user.
  • the SIP identifier of the push program is generated, where the user part carries the CoD content identifier, where is the content-1, and the domain name part is the domain name of the SCF entity.
  • the SIP identity is carried by the From header field;
  • the offer is initiated by carrying the SDP in the message body, and the offer information is obtained from the 200 OK of the MF entity response.
  • Core IMS forwards the SIP INVITE to the UE entity
  • the UE receives and parses the SIP INVITE, including:
  • Detecting the P-Preferred-Service if carrying the push service tag (urn: xxx: iptv.sessionpush), it can be processed based on the local application, for example, triggering the push service logic, and presenting the pushed program information to the user when the user starts watching the program;
  • the Core IMS forwards the 200 OK message to the SCF entity. 709.
  • the SCF receives and parses the 200 OK message, including:
  • the MF entity receives and parses the ACK message, obtains an SDP answer, and completes media negotiation.
  • the service control function entity provides a standard interface, and pushes the service information to trigger the push service logic to complete the push service.
  • the embodiment of the invention provides a push method for the user subscription information Push CoD service, and each application function only needs to complete the corresponding application logic management, and does not need to repeatedly implement session negotiation and media negotiation, etc.
  • the deployment efficiency of new application features simplifies the complexity of the network.
  • the present invention further provides another specific embodiment of the service pushing method.
  • the service provider provides a timed switching service through a value-added application function (AF) entity, and the SCF entity receives the push.
  • the request can also be initiated to the push service receiving unit through the SIP REFER.
  • the user switches the service when the AF entity signs the agreement.
  • the proxy user initiates a service indication to the SCF entity, initiates a scheduled handover push service, and the SCF entity initiates a handover request through the SIP REFER.
  • the method includes:
  • the AF entity triggers the timing switching service logic, and generates the push service information according to the user subscription information, including the user information to be pushed, the channel information to be pushed, and the like; the AF entity sends the push service information to the SCF entity through the SIP MESSAGE. among them:
  • the Request-URI is a SIP identifier of the SCF entity, and is used to route the SIP message to the SCF entity, which may be a PSI.
  • the P-Preferred-Service header field contains a push service tag.
  • the SIP MESSAGE message body contains the service information to be pushed.
  • the MESSAGE message body may also carry related media parameter information.
  • the SCF entity receives and parses the SIP MESSAGE, including:
  • Detecting the Accept-Contact header field determining the push service by pushing the service tag; detecting and parsing the message body, and obtaining the push service information, including pushing the user information;
  • the SCF entity sends a successful response to the AF entity.
  • the SCF entity triggers the push service logic according to the push service identifier, including:
  • Pushing a service request to the user UE according to the user identifier obtained from the push service information here is a SIP REFER, where:
  • the Request-URI is a SIP identifier of the user obtained from the push service information.
  • Refer-To is the SIP identifier of the push advertisement.
  • the user part carries the channel identifier in the SIP identifier, and is obtained from the push service information.
  • the domain name part in the SIP identifier is the domain name of the SCF entity.
  • the push service tag may be carried in the Accept-Contact header field, and is used to indicate that the UE requests the push service request;
  • the media parameter information of the push content can be carried through the message body, and the Content-Type should be application/sdp.
  • the Core IMS forwards the SIP REFER to the UE.
  • the UE processes the SIP REFER, including:
  • the UE may trigger the push service logic based on the identifier
  • the UE may obtain the push content identifier through the user part part of the SIP identifier in the Refer-To header field;
  • the UE can obtain the media parameters.
  • UE response REFER
  • the UE initiates a service request according to the REFER indication, and completes the channel switching.
  • the media information of the push content needs to be obtained, including the media format, the bandwidth information, and the like.
  • the information may be obtained by the service triggering function entity and then carried to the service by the push service request in the manner given in the foregoing embodiment.
  • the control function entity may be implemented by an entity that needs such information, such as a service control function entity, according to the content identifier, and other manners, and is not described here.
  • the embodiment of the present invention implements the push service logic to trigger the push service logic, and negotiates to complete the push service logic; the network side may initiate the session to push the required content to the user; the general push function of the service may be implemented, and subsequent specific pushes may be implemented. Business; can effectively improve the deployment of applications and simplify the complexity of the network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Telephonic Communication Services (AREA)

Description

业务推送协商方法及装置、 推送业务系统 本申请要求 2008年 9月 10日递交的申请号为 200810198463.8、 发明名 称为 "业务推送协商方法及装置、 推送业务系统" 的中国专利申请的优先 权， 其全部内容通过引用结合在本申请中。 技术领域
本发明涉及网络业务推送领域， 具体地涉及一种业务推送协商方法及装 置、 推送业务系统。 背景技术
网络电视 （Internet Protocol Television, IPTV) 基于多媒体子系统 （IP Multimedia Subsystem, IMS ) 即通过 IMS网络提供 IPTV业务， 以充分利用 IMS网络中已有的注册、 认证、 路由、 会话控制与建立、 业务触发、 计费、 端到端的服务质量 （Quality of Service, QoS ) 保证等机制来为用户提供流 媒体业务及融合流媒体和实时会话业务的多媒体业务。
目前 TISPAN等标准组织已经制定了 IPTV基于 IMS ( IMS Based IPTV) 网络相关标准， 业务 /内容提供商可以通过 IMS Based IPTV网络为用 户提供直播 （Broadcast, BC ) ， 内容点播 （Content on Demand, CoD) 等 基本 IPTV业务， 而这些基本业务通常都是由用户发起业务请求并完成相关 的媒体协商及会话建立的； 如图 1所示的 TISPAN IMS Based IPTV网络架 构， 该架构包括：
业务发现功能 （Service Selection Function, SSF) 实体与业务选择功能 ( Service Discovery Function, SDF) 实体： 提供业务导航功能， 包括业务发 现信息及业务选择信息； 业务控制功能 （Service Control Function, SCF) 实体： 提供基本业务的 业务授权、 会话管理等功能， 目前包括 BC、 CoD等基本业务的业务控制功 能；
媒体功能 （Media Function, MF) 实体： 提供媒体流的控制和交付。 但是现有技术中， 除了这些基本业务， 还存在一些增强的 IPTV业务需 要通过网络侧主动发起会话向用户推送内容的需求， 例如用户可以在网络中 预先登记业务， 当某频道的节目开始播出时将用户正在收看的节目切换到该 频道； 或者用户向网络登记自己感兴趣的节目类型， 当网络中有相关的节目 部署时， 网络侧主动将该内容推送到用户终端， 还有其他一些可能需求， 都 要求网络能够主动向用户推送一些内容， 而目前的网络中并没有提供解决方 案。 发明内容
本发明所要解决的技术问题在于， 提供一种业务推送协商方法及装置、 推送业务系统， 可通过网络侧主动发起会话向用户推送需要的内容， 并通过 推送业务信息触发推送业务逻辑， 协商完成推送业务逻辑。
为了解决上述技术问题， 本发明实施例提出了一种业务推送协商方法， 所述方法应用于网络电视基于多媒体子系统 IMS Based IPTV网络， 所述方 法包括：
接收推送业务信息， 所述推送业务信息携带推送业务标识；
解析所述推送业务信息；
根据所述推送业务信息触发推送业务逻辑， 发送推送业务请求， 所述推 送业务请求携带推送内容标识；
协商完成所述推送业务逻辑。
相应地， 本发明实施例还提供了一种业务推送协商装置， 所述装置应用 于网络电视基于多媒体子系统 IMS Based IPTV网络， 所述装置包括： 接收单元， 用于接收推送业务信息， 所述推送业务信息携带推送业务标 识；
解析单元， 用于解析所述接收单元所接收的推送业务信息；
发送单元， 用于根据所述推送业务信息触发推送业务逻辑， 发送推送业 务请求， 所述推送业务请求携带推送内容标识；
协商单元， 用于协商完成所述推送业务逻辑。
相应地， 本发明实施例还提供了一种业务推送系统， 所述系统应用于网 络电视基于多媒体子系统 IMS Based IPTV网络， 所述系统包括应用功能实 体、 业务控制功能实体和接收功能实体；
所述应用功能实体用于发送推送业务信息给所述业务控制功能实体， 所 述推送业务信息携带推送业务标识；
所述业务控制功能实体用于接收所述应用功能实体发送的推送业务信 息； 并解析所接收的所述推送业务信息； 以及根据所述推送业务信息触发推 送业务逻辑， 发送推送业务请求， 所述推送业务请求包括推送内容标识； 与 所述接收功能实体协商完成所述推送业务逻辑；
所述接收功能实体用于接收所述业务控制功能实体发送的推送业务请 求； 与所述业务控制功能实体协商完成推送业务逻辑。 附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实 施例或现有技术描述中所需要使用的附图作简单地介绍， 显而易见地， 下面 描述中的附图仅仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动性的前提下， 还可以根据这些附图获得其他的附图。
图 1是现有的 TISPAN IMS Based IPTV网络架构的结构示意图； 图 2是本发明实施例的业务推送协商方法的流程示意图；
图 3是本发明实施例的业务推送协商装置的结构示意图； 图 4是本发明实施例的业务推送系统的结构示意图；
图 5为本发明的业务推送协商方法的具体实施例一的示意图； 图 6为本发明的业务推送协商方法的具体实施例二的示意图； 图 7为本发明的业务推送协商方法的具体实施例三的示意图。 具体实施方式
下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进行 清楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而 不是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没有作 出创造性劳动前提下所获得的所有其他实施例， 都属于本发明保护的范围。
图 2是本发明实施例的业务推送协商方法的流程示意图， 该方法应用于 IMS Based IPTV网络， 如图 2所示， 该方法包括：
201 , 接收推送业务信息， 所述推送业务信息携带推送业务标识； 所述推送业务标识可以包括频道信息、 节目信息或者内容信息； 上述推送业务信息还可以包括以下信息的任意一种或者多种： 接收推送业务的用户信息；
接收推送业务的用户列表信息；
推送业务开始执行的时间信息；
推送应用相关信息。
推送业务信息可以基于会话描述协议 （ Session Description Protocol，
SDP) 或者可扩展标记语言 （Extensible Marked Language, XML) 定义， 采 用 XML定义时如下所示：
<?xml version:" 1.0" encoding="UTF-8"?>
<xs: schema xmlns:xs="http://www.w3. org/2001/XMLSchema"
targetNamespace="urn:xxx:xml:ns:iptvpushserviceactiondata"
elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs: element name="IPTVPushActionData">
<xs： complexType>
<xs:sequence>
<xs: element name="UserList" type="xs:anyURI"/> <xs: element name="PushContentId" type="xs:string"/>
<xs: element name="StartTime" type="xs:time" minOccurs="0"/>
<xs: element name="Duration" type="xs:unsignedlnt" minOccurs="0"/>
<xs:element name="Transparence" minOccurs="0">
<xs： complexType>
<!_这里为推送应用相关信息， 与具体 的应用相关， 不需要解析该信息， 如果包含该信息， 将该信息直接转发 >
< >
</xs： complexType>
</xs:element>
</xs:sequence>
</xs： complexType>
</xs:element>
</xs:schema>
推送业务信息还可以通过会话启动协议 （Session Initiation Protocol , SIP ) 消息体携带发送， 例如 MESSAGE， SUBSCRIBE/NOTIFY， INVITE , INFO等携带； 也可以通过超文本传输协议 （Hypertext Transfer Protocol, HTTP ) 等其它协议消息体携带； 也可以通过 SIP头域携带。
推送业务信息中需要包含指示该信息为推送业务信息的推送业务标识； 推送业务标识也可以通过 SIP消息体或者 HTTP等其它协议消息体携 带， 例如可以通过新定义消息实体类型 （Content-Type ) 定义推送业务标 识， 例如新定义消息实体类型： application/iptv-push+xml；
通过 SIP或者 HTTP等其它协议消息体携带推送业务标识时， 也可以通 过 XML定义推送业务标识， 如下所示 XML定义：
<?xml version:" 1.0" encoding="UTF-8"?>
<xs: schema xmlns:xs="http://www.w3. org/2001/XMLSchema" xmlns： adc="urn:xxx： xml:ns： iptvactiondatacommand"
targetNamespace="urn： xxx： xml： ns： iptvactiondatacommand"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs: element name="IPTVActionDataCommand">
<xs： complexType>
<xs:choice>
<xs: element name=" SessionPush" type="adc:tSessionPush" minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs： complexType>
</xs:element>
<xs： complexType name="tSessionPush">
<!-SessionPush 的类型定义， 可以包含推送业务信息的属性定 义 〉
</xs： complexType>
</xs:schema>
通过 SIP头域携带推送业务标识时， 也可以通过新定义媒体特性标签 (media feature tag) 及属性值标识定义推送业务标识， 例如定义新的媒体特 十生标签" +iptv.appid"， 并且为推送业务定义值域" urn:xxx:iptv:sessionpush"， 即通过媒体特性标签 +iptv.appid="urn:xxx:sessionpush"标识推送业务；
媒体特性标签可以通过 SIP头域携带， SIP头域可以是新定义头域或者 Accept-Contact等现有头域， 例如：
Accept-contact:*; +iptv.appid="urn:xxx:sessionpush" 也可以直接通过 SIP头域携带推送业务属性值标识为推送业务， 例如：
P-Preferred-Service: urn:xxx:iptv:sessionpush。
202, 解析所述推送业务信息；
其中， 202进一歩包括：
根据所述推送业务标识确定所述推送业务信息为推送业务请求； 获取推送业务接收用户标识信息、 推送业务的推送内容标识、 推送业务 推送时间信息中的任意一种或者多种。
202中通过推送业务标识确定该推送业务信息为推送业务请求； 可以通 过 Content-Type确定并获取推送业务信息， 例如检测 Content-Type 为 "application/iptv-push+xml"； 还可以通过 XML中的元素确定为推送业务请 求 ， 例 如 按 照 上 述 的 XML 定 义 ， 当 检 测 到 ： IPTVActionDataCommand="SessionPush"， 则确定为推送业务请求； 还可以 通过检测 SIP头域中携带的业务指示信息确定是否为推送业务请求， 例如通 过 P-Preferred- Service： urn:xxx:iptv:sessionpush, 确定该 SIP消息用于角虫发推 送业务的推送业务请求；
同时， 可以根据 XML定义解析推送业务信息， 获取下面的一种或者多 种信息：
推送业务接收用户标识信息；
推送业务的推送内容标识；
推送业务推送时间信息。
203， 根据所述推送业务信息触发业务逻辑， 发送推送业务请求， 所述 推送业务请求携带推送内容标识；
203中， 通过生成 SIP请求发起推送业务请求， 其中， 推送业务请求中 的 SIP Request-URI设置为推送业务接收用户标识， 当推送业务接收设备为 用户 IPTV UE时， 这里标识可以是 IMS公共用户标识 （IMS Public User Identity, IMPU) ； 业务推送请求中需要携带推送业务推送内容标识， 可以通过 SIP From 头域所携带的 SIP标识中的 user part携带；
推送内容标识也可以通过 SIP消息体携带， 这种情况下推送内容标识可 以通过 xml定义并携带， 例如通过上述 201中所定义的 IPTVPushActionData 携带；
推送业务请求中可以携带推送业务标识， 推送业务标识可以通过 SIP头 域携带， 例如 P-Preferred-Service: urn:xxx:iptv:sessionpush;
另外， 也可以通过 SIP消息体携带， 这种情况下可以通过 xml定义并携 带推送业务标识 ， 例 如 通过携 带上述 201 中 所述及 的 IPTVActionDataCommand=
"sessionpush";
可选地， 推送业务请求还可以携带除推送业务标识外， 推送业务信息包 括的信息中的任意一种或者任意组合； BP , 所述推送业务请求还可以携带所 述推送业务信息包括的信息中的任意一种或者任意组合， 实施中可通过 SIP 头域或者 SIP消息体， 携带所述推送业务信息包括的信息中的任意一种或者 任意组合。
如果接收到了透明信息， 这里可以通过 IPTVPushActionData将透明信 息透传出去。
其中， 203包括：
获取所述推送业务信息中的接收推送业务的用户信息或者用户列表信 息；
给用户信息中的用户或者用户列表信息中用户列表的用户发送推送业务 请求；
上述推送业务请求为 SIP请求， 可以是 INVITE、 MESSAGE, REFER 等消息。
204， 协商完成所述推送业务逻辑。 204中， 可以根据推送内容标识确定待接收的推送信息；
推送内容标识可以从 SIP From头域所携带 SIP标识 user part获取； 或 者从消息体中获取；
还可以根据推送业务标识执行本地推送业务逻辑；
推送业务标识可以从 SIP头域中获取， 例如
P-Preferred-Service: urn:xxx:iptv:sessionpush; 或者，
推送业务标识通过解析 SIP消息体获取， 例如
IPTVActionDataCommand="sessionpush"
还可以解析透明信息， 并完成推送应用相关的业务逻辑。
实施本实施例， 通过推送业务信息触发推送业务逻辑， 协商完成推送业 务逻辑； 可通过网络侧主动发起会话向用户推送需要的内容； 同时可以有效 地提高应用的部署， 简化网络的复杂度。
图 3是本发明实施例的业务推送协商装置的结构示意图， 该装置应用于 IMS Based IPTV网络， 如图 3所示， 该装置包括：
接收单元 10， 用于接收推送业务信息， 所述推送业务信息携带推送业 务标识；
解析单元 11， 用于解析所述接收单元 10所接收的推送业务信息； 发送单元 12， 用于根据所述推送业务信息触发推送业务逻辑， 发送推 送业务请求， 所述推送业务请求携带推送内容标；
协商单元 13， 用于协商完成所述推送业务逻辑。
进一歩地， 解析单元 11包括：
确定单元 110， 用于根据所述推送业务标识确定所述推送业务信息为推 送业务请求；
获取单元 111， 用于获取推送业务接收用户标识信息、 推送业务的推送 内容标识、 推送业务推送时间信息三种中的任意一种或者多种。 所述推送业务标识包括频道信息、 节目信息或者内容信息； 该装置实施 例中所述及的推送业务信息还可以包括以下信息的任意一种或者多种：
接收推送业务的用户信息；
接收推送业务的用户列表信息；
推送业务开始执行的时间信息；
推送应用相关信息。
本实施例的业务推送协商装置为业务控制单元， 该单元可以在 IPTV网 络中的业务控制功能实体中实现。
图 4是本发明实施例的业务推送系统的结构示意图， 该系统应用于 IMS Based IPTV网络， 如图 4所示， 该系统包括应用功能实体 1、 业务控制功能 实体 2和接收功能实体 3;
所述应用功能实体 1 用于发送推送业务信息给所述业务控制功能实体 2， 所述推送业务信息携带推送业务标识； 这里的应用功能实体 1在具体实 施中可以体现为推送业务触发单元， 推送业务触发单元可以在用户 IPTV终 端实现， 或者其它功能实体上实现， 例如后台配置功能， 独立的增强功能等 实体。
所述业务控制功能实体 2用于接收所述应用功能实体 1发送的推送业务 信息； 并解析所接收的所述推送业务信息； 以及根据所述推送业务信息触发 推送业务逻辑， 发送推送业务请求， 所述推送业务请求包括推送内容标识； 与所述接收功能实体 3协商完成所述推送业务逻辑； 这里的业务控制功能实 体 2在具体实施中可以体现为业务控制单元， 业务控制单元可以在 IPTV网 络中的业务控制功能 （SCF) 实体实现， 其功能结构如图 3的业务推送协商 装置所述。
所述接收功能实体 3用于接收所述业务控制功能实体 2发送的根据所述 推送业务信息所生成的推送业务请求， 所述推送业务请求携带推送内容标 识； 与所述业务控制功能实体 2协商完成推送业务逻辑。 这里的接收功能实 体 3在具体实施中可以体现为推送业务接收单元， 通常在用户 IPTV终端实 现。
所述应用功能实体 1 和业务控制功能实体 2可以分别是单独的功能实 体， 或者是合设成一个功能实体； 所述应用功能实体 1和接收功能实体 3可 以分别是单独的功能实体， 或者是合设成一个功能实体。
可选地， 在实际具体实施例中， 应用功能实体 1与接收功能实体 3可以 合并成一个功能实体， 或者应用功能实体 1与业务控制功能实体 2合并成一 个功能实体， 实现应用功能实体 1、 业务控制功能实体 2、 接收功能实体 3 作为单个实体时所具有的功能。
实施本发明系统的实施例， 通过推送业务信息触发推送业务逻辑， 协商 完成推送业务逻辑； 可通过网络侧主动发起会话向用户推送需要的内容； 可 以实现业务通用的推送功能， 后续各种具体的推送业务； 可以有效地提高应 用的部署， 简化网络的复杂度。
下面结合图 2至图 4对图 5的业务推送协商方法进行进一歩详细地说 明。
如图 5所示， 图 5为本发明的业务推送协商方法的具体实施例一的示意 图。
在本实施例中， 应用功能实体 （推送业务触发单元） 和接收功能实体 (推送业务接收单元） 在 UE上实现， 业务控制功能实体即业务控制单元在 SCF实体上实现。 用户通过 UE浏览节目导航信息等确定待切换的节目信 息， UE按照推送业务信息格式生成定时频道切换定制请求， 即推送业务请 求， 包括待推送的用户标识、 频道标识及切换时间信息； SCF实体接收用户 通过 UE发起的定时频道切换定制请求， 并根据定制请求中包含的用户信 息、 节目信息及时间信息在条件满足时触发推送业务逻辑， 向指定用户发起 频道切换请求。
该方法包括： 501 , UE通过 SIP消息 （SIP MESSAGE) 发起频道切换定制请求， 其 中：
Request-URI为 SCF的 PSI标识；
SIP MESSAGE消息体中包含频道切换信息， 这里 UE基于推送业务信 息模板生成频道切换信息， 包含推送业务信息， 推送业务信息中包含推送业 务标识。
MESSAGE sip: bc-scf. iptv.com SIP/2.0
To: <sip:bc-scf.iptv.com>
Content-Type: application/xml
Content-Length: 127
<?xml version:" 1.0" encoding="UTF-8"?>
<IPTVActionDataCommand
>
<SessionPush>
<push:IPTVPushActionData>
<UserList>sip:user-a@iptv.com</UserList>
<PushContentId>Channel- 1 </PushContentId>
<StartTime>21 :00:00</StartTime>
</push:IPTVPushActionData>
</SessionPush>
</IPTVActionDataCommand>
502, 核心 IMS ( Core IMS ) 向 SCF实体转发 SIP MESSAGE;
503 , SCF实体接收并解析 SIP MESSAGE, 该过程包括：
检测并解析消息体， 根据 xml中包含 "IPTVActionDataCommand"元素， 并且值域为" SessionPush"确定为触发推送业务逻辑； 检测并解析消息体， 从 xml中' 'IPTVPushActionData"元素的值域获取推 送业务信息；
SCF实体可以根据推送业务信息中的用户标识 （UserList) 、 内容标识 (PushContentld) 确定用户是否有收看该节目的权限；
本实施例中 SCF实体确定在 21 :00时向用户 sip:user-a@iptv.com发起
Channel- 1的推送请求。
504， SCF实体确定用户可以完成定时切换， 向 UE发送成功响应消息 (200OK消息) ；
505 , Core IMS向 UE转发成功响应消息；
506， SCF实体根据获取的推送业务信息及媒体参数信息发起推送业务 请求， 本实施例中为 SIP INVITE, 其中：
Request-URI为从推送业务信息中获取的用户标识 （UserList) ；
From 头域携带从推送业务描述信息中获取待切换的频道标识 (PushContentld) ， 这里为 SIP标识， 其中 user part部分携带频道标识， 域 名部分为 SCF的域名；
P-Preferred-Service 头 域 中 可 以 携 带 推 送 业 务 标 识 urn:xxx:iptv.sessionpush, 用于向用户终端指示当前发起的为推送业务请求；
Content-Type包含 application/sdp类型， 通过 SDP offer发起媒体协商， 携带待推送频道的媒体参数信息；
INVITE sip: user-a@iptv.com SIP/2.0
From: <sip: Channel- 1 @cod-scf.iptv.com>;tag=31417
To: <sip:user-a@iptv.com>
P-Preferred- Service： urn:xxx:iptv.sessionpush 待推送频道的媒体参数信息包括组播地址、 媒体格式、 带宽等一种或者 多种信息。 这里 SCF实体可以通过多种方式获取媒体参数信息， 包括： SCF实体上预先配置保存相关的信息；
SCF实体根据频道标识通过 SIP或非 SIP请求从保存有媒体参数信息的 功能实体获取媒体参数信息。
507, Core IMS向 UE转发推送业务请求；
508， UE解析收到的推送业务请求， 获取待推送的频道信息及媒体参 数信息， 并通过发送 200 OK消息做出响应。 这里 UE可以基于推送业务标 识、 频道信息等通过 UE本地应用向用户呈现相关信息， 为用户提供选择， 例如是否切换到该频道， 用户可以通过遥控器做出选择， UE基于用户的选 择做出响应， 当用户选择同意切换时 UE再发起成功响应；
509, Core IMS向 SCF实体转发 200OK消息；
510, SCF实体接收到 UE发送的 200OK消息， 完成会话建立；
511， UE接收媒体流， UE根据会话协商中获取的多播地址加入多播组 接收媒体流， 完成频道切换。
本实施例提供的业务推送方法中， 业务控制功能实体对外提供标准接 口， 通过推送业务信息触发推送业务逻辑， 完成推送业务。 本发明实施例提 供了一种频道定制切换业务的推送方法， 各应用功能本身只需要完成相应的 应用逻辑管理即可， 不需要重复实现会话协商及媒体协商等功能， 可以有效 地提高新应用功能的部署效率， 简化网络的复杂度。
如图 6所示， 图 6为本发明的业务推送协商方法的具体实施例二的示意 图。
本实施例中的应用功能实体 （推送业务触发单元） 在广告功能 (Advertise Function, ADF ) 实体上实现， 接收功能实体 （推送业务接收单 元） 在 UE上实现， 业务控制功能实体 （业务控制单元） 在 SCF实体上实 现。 这里的 ADF实体可以是后台配置功能实体， 也可以是一个应用功能实 体； 本实施例中广告媒体由媒体功能 （Media Function, MF ) 提供， 实际部 署中也可能是由其它功能实体提供， 例如直接由 ADF实体提供广告媒体， 也可能是由其它实体提供给 MF， 再由 MF转发给 UE; 这些情况与具体的 广告业务相关。
该方法包括：
601， BC节目中的广告时间到达， 广告服务器触发业务逻辑， 通过单 播方式向用户提供个性化广告， 广告服务器根据推送业务信息模板生成推送 广告信息， 其中包括待推送的用户信息， 待推送的广告信息等； 广告服务器 通过 SIP MESSAGE向 SCF实体发送推送业务信息， 其中：
Request-URI为 SCF实体的 SIP标识， 用于将 SIP消息路由到 SCF, 可 以是 PSI;
P-Preferred-Service头域中包含推送业务标签；
SIP MESSAGE消息体中包含待推送业务信息；
另外， 如果 ADF实体提供广告的媒体参数， MESSAGE消息体中也可 以携带广告的媒体参数信息， 媒体参数通常通过 SDP携带；
SIP 消息中携带多种类型的消息体， 考虑 Content-Type 使用 multipart/mixed类型， 可通过 SDP和 XML共同对推送业务信息进行定义。
MESSAGE sip: cod-scf.iptv.com SIP/2.0
From: <sip:adf.iptv.com>;tag=31415
To: <si : cod- scf . iptv. com>
P-Preferred- Service： urn:xxx:iptv.sessionpush
Content- Type: multipart/mixed； boundary="boundry 1
Content-Length: 127
—boundryl Content- Type: application/iptvsad-sessionpush+xml
<?xml version:" 1.0" encoding="UTF-8"?>
<IPTVPushActionData
>
<UserList>sip:user-a@iptv.com</UserList>
<PushContentId>Ad- 1 </PushContentId>
<StartTime>21 :00:00</StartTime>
<Duration> 180</push-d:Duration>
</IPTVPushActionData>
—boundryl
Content- Type: application/sdp t=0 0
c=IN IP4 192.168.0.1 m=audio 0 RTP/AVP 0
b=AS:64
m=video 0 RTP/AVP 99
b=AS: 128
a=rtpmap:99 h263- 1998/90000
602, SCF实体接收并解析 SIP MESSAGE, 并向 ADF实体发送成功响 应消息， 包括：
检 测 SIP 消 息 头 域 中 包 含 "P-Preferred-Service: urn:xxx:iptv.sessionpush" , 确认为推送业务消息；
检测并解析消息体， 根据 application/iptvsad-sessionpush消息类型获取 推送业务信息， 包括推送内容标识 （ PushContentld ) ， 待推送用户信息 (UserList) ， 推送时间信息 ( StartTime, Duration) ； 检测并解析消息体， 如果包含 application/sdp， 则获取推送内容的媒体 参数信息。
603 ， SCF 实 体 根 据 推 送 业 务 标 识 （ P-Preferred-Service: urn:xxx:iptv.sessionpush ) 触发推送业务逻辑， 发起推送业务请求， 这里为 SIP INVITE:
从推送业务描述信息中获取用户标识， 作为 Request-URI发起会话请 求；
从推送业务描述信息中获取待推送的广告标识， 作为 user part部分， 与 SCF实体的域名共同组成 SIP标识， 并通过 From头域携带；
推送业务请求中还可以通过 P-Preferred-Service头域携带推送业务标 识， 向 UE指示该请求为推送业务请求；
SCF实体还可以通过 SIP INVITE消息体携带广告内容的媒体信息， 本 实施例中媒体参数信息由 ADF实体在发起推送业务请求时通过 SDP携带；
INVITE sip: user-a@iptv.com SIP/2.0
From: <sip:Ad-l@cod-scf.iptv.com>;tag=31417
To: <sip:user-a@iptv.com>
P-Preferred- Service： urn:xxx:iptv.sessionpush
Content- Type: application/sdp t=0 0
c=IN IP4 192.168.0.1 m=audio 0 RTP/AVP 0
b=AS:64
m=video 0 RTP/AVP 99 b=AS: 128
a=rtpmap:99 h263- 1998/90000
604， Core IMS向 UE转发 SIP请求消息；
605， UE接收并解析 SIP请求消息；
如果 SIP请求消息通过 P-Preferred-Service头域携带了推送业务标识，
UE可以基于该标识触发推送业务逻辑完成推送业务相关的处理；
UE解析 From头域携带的 SIP标识， 从 user part获取推送广告标识， 这 里为 Ad-1 ;
如果 SIP请求消息通过消息体携带 Ad-1的 SDP媒体参数信息， 需要从 SDP获取这些信息；
UE检测确定 SCF实体没有发起 SDP offer, 因此通过响应消息发起 SDP offer进行媒体参数协商； 这里可以通过 200 OK响应发起 SDP offer;
606， Core IMS向 SCF实体转发 200OK响应消息；
607, SCF实体接收并解析 UE的 200OK响应消息， 向选定的 MF实体 发起新的 INVITE请求； 从响应消息中携带的 SDP offer中获取媒体参数信 息； 根据广告标识选择合适的 MF实体， 选择 MF实体时可以参考 UE的位 置信息等其它信息共同决策；
其中：
Request-URI为选定 MF实体的 SIP标识；
To头域中携带请求广告内容的 SIP标识， 可以由两个部分组成， 其中 user part携带广告内容标识， 这里为 Ad-1， 域名部分为 MF实体的标识； 可以通过 P-Preferred-Service头域携带推送业务标识， 指示该请求为推 送业务请求；
通过消息体携带 UE发送的 SDP offer, 代理 UE发起媒体协商；
INVITE sip: cod-mcf.iptv.com SIP/2.0 From: <sip:cod-scf.iptv.com>;tag=71413
To: <sip: Ad- 1 @cod-mcf.iptv.com>
P-Preferred- Service： urn:xxx:iptv.sessionpush 608， MF实体接收并解析 SIP请求消息， 完成业务处理， 并返回响 应， 携带 SDP answer; 这里可以通过 200 OK返回响应。
609， SCF实体接收并解析 MF实体发送的 200 OK消息， 并进行与 UE 的媒体协商； 终结 MF实体的响应消息， 建立 SCF实体与 MF实体之间的 SIP会话； 获取 MF实体响应携带的 SDP answer中的媒体参数； 通过 ACK 消息响应 UE的 200 OK响应， 并通过 SDP answer携带从 MF实体获取的媒 体参数。
610， Core IMS向 UE转发 ACK消息；
611， UE接收并处理 ACK消息， 获取 SDP answer中的媒体参数， 并通 过 200 OK消息响应确认；
612， Core IMS向 SCF实体转发 200 OK消息；
613， SCF实体接收并处理 200 OK消息， 建立 UE与 SCF实体之间的 SIP会话；
614， UE根据协商的媒体参数直接与 MF实体之间建立媒体传送和 /或 媒体控制通道。
本实施例提供的业务推送方法中， 业务控制功能实体对外提供标准接 口， 通过推送业务信息触发推送业务逻辑， 完成推送业务。 本发明实施例提 供了一种广告业务的推送方法， 各应用功能本身只需要完成相应的应用逻辑 管理即可， 不需要重复实现会话协商及媒体协商等功能， 可以有效地提高新 应用功能的部署效率， 简化网络的复杂度。
图 7为本发明的业务推送协商方法的具体实施例三的示意图， 用户签约
Push CoD业务时， 应用推送功能 （Push Application Function, PAF) 实体根 据用户的签约、 喜好等向用户提供内容自动下载业务， 即网络侧主动向用户 终端下载内容， 无需用户的参与。 该方法包括：
701 , PAF实体根据用户签约信息触发 Push CoD业务逻辑， 向 SCF实 体发起推送业务请求完成 CoD 内容的推送。 推送业务请求中需要携带推送 业务标识， 用于指示 SCF实体该请求为推送业务请求， 同时还需要携带推 送业务信息， 推送业务信息基于 SCF实体提供的接口模板生成， 包含下面 一些信息： 接收推送内容的用户标识、 推送的 CoD内容标识、 推送 CoD的 媒体描述信息， 其中媒体描述信息可以包括推送的媒体协议格式， 媒体属性 等。
PAF实体可以通过 SIP MESSAGE向 SCF实体发起推送业务请求， 其 中：
Request-URI包含路由 SIP请求到 SCF实体的 SIP标识， 可以是 PSI; SIP MESSAGE消息体中包含待推送业务触发信息， 包括推送业务指示 以及推送业务信息；
MESSAGE sip: cod-scf.iptv.com SIP/2.0
From: <si ： af. iptv.com>;tag=31415
To: <si : cod- scf . iptv. com> Content- Type: application/ xml:
Content-Length: 127
<?xml version:" 1.0" encoding="UTF-8"?>
<IPTVActionDataCommand
>
<SessionPush>
<push:IPTVPushActionData>
<push:UserList>sip:user-a@iptv.com</push-d:UserList> <push： PushContentId>Content- 1 </push-d:PushContentId> <push： Duration>5400</push-d:Duration>
</push:IPTVPushActionData>
</SessionPush>
</IPTVActionDataCommand>
702, SCF实体接收 SIP MESSAGE, 向 PAF实体发送成功响应， 并解 析接收到的 SIP MESSAGE。 SCF实体根据推送请求中的推送业务标识确定 为触发推送业务逻辑， 并且从推送请求消息体中获取推送业务信息。 本实施 例中包括：
解析 xml， 通过元素 IPTVActionDataCommand值域为为 SessionPush确 定为推送业务；
解析 xml， 通过元素 IPTVPushActionData的值域获取待推送用户信息 ( UserList ) ， 待推送节目信息 （ PushContentld ) ， 待推送节目的时长 ( Duration ) 。
703， SCF实体向 MF实体发起推送业务请求， 包括：
基于获取的推送业务内容标签， 本实施例中为 CoD标识 Content- 1， 选 择合适的 MF实体；
SCF实体向 MF实体发起推送业务请求， 本实施例中为 SIP请求消息 ( SIP INVITE) ， 其中：
Request-URI为路由到选定 MF实体的 SIP标识， 例如 PSI;
To头域中携带请求 Push的 CoD SIP标识， 可以由两个部分组成， 其中 user part携带 CoD内容标识， 这里为 Content-l， 域名部分为 MF实体的域 名；
可以通过 P-Preferred-Service头域携带推送业务标识， 指示该请求为推 送业务请求。
704， MF实体接收并解析 SIP请求消息， 包括： 如果请求中携带了推送业务标签， 解析 P-Preferred-Service获取推送业 务标签， 确定该业务请求为推送业务请求， 可以指示 MF实体处理推送业务 逻辑；
解析获取节目标识， 本实施例中为解析 To头域获取节目标识， 这里为 Content- 1 , 并为传输 Content-1内容流分配端口号等参数；
生成 200 OK响应消息， 并携带 SDP offer, 携带相关媒体参数， 包括 Content-1的媒体描述信息及 IP地址、 端口号等。
705 , SCF实体接收并解析 200 OK消息， 包括：
从 200 OK消息中获取 SDP offer信息， 并根据 702中获取的用户标识 发起推送业务请求， 该请求为 SIP INVITE, 其中：
Request-URI为用户 SIP标识；
生成推送节目的 SIP标识， 其中 SIP标识中 user part携带 CoD内容标 识， 这里为 Content-1， 域名部分为 SCF实体的域名。 SIP标识通过 From头 域携带；
可以携带 P-Preferred-Service头域， 并携带推送业务标签；
通过消息体中携带 SDP发起 offer, 该 offer信息从 MF实体响应的 200 OK中获取。
706, Core IMS向 UE实体转发 SIP INVITE;
707, UE接收并解析 SIP INVITE, 包括：
从 From头域携带 SIP标识 user part获取 CoD内容标识；
检 测 P-Preferred-Service ， 如 果 携 带 推 送 业 务 标 签 (urn:xxx:iptv.sessionpush) ， 可以基于本地应用进行处理， 例如触发推送业 务逻辑， 在用户开机收看节目时向用户呈现推送的节目信息等；
获取 SDP offer中的携带的媒体参数， 并生成 SDP answer;
通过 200 OK响应 SCF实体的请求， 并携带 SDP answer。
708, Core IMS向 SCF实体转发 200 OK消息； 709, SCF接收并解析 200 OK消息， 包括：
通过 ACK消息响应 UE发起的 200 OK;
通过 ACK消息响应 MF实体发起的 200 OK, 该 ACK消息中携带 UE 发送的 SDP answer;
710， MF实体接收并解析 ACK消息， 获取 SDP answer, 完成媒体协 商；
711， UE与 MF实体之间通过 SCF实体完成媒体协商， 建立媒体传送 通道。
本实施例提供的业务推送方法中， 业务控制功能实体对外提供标准接 口， 通过推送业务信息触发推送业务逻辑， 完成推送业务。 本发明实施例提 供了一种用户签约信息 Push CoD业务的推送方法， 各应用功能本身只需要 完成相应的应用逻辑管理即可， 不需要重复实现会话协商及媒体协商等功 會^ 可以有效地提高新应用功能的部署效率， 简化网络的复杂度。
同时， 本发明还提供了业务推送方法的另一种具体实施例， 本实施例中 服务提供商 （Service Provider, SP ) 通过增值应用功能 （AF ) 实体提供定 时切换业务， SCF实体在接收到推送业务请求后， 还可以通过 SIP REFER 向推送业务接收单元发起请求。 用户在 AF实体签约定时切换业务， 当 AF 实体监控到切换时间到达， 代理用户向 SCF实体发起业务指示， 启动定时 切换推送业务， SCF实体通过 SIP REFER发起切换请求。 该方法包括：
定时切换时间到达， AF实体触发定时切换业务逻辑， 根据用户签约信 息生成推送业务信息， 其中包括待推送的用户信息， 待推送的频道信息等； AF实体通过 SIP MESSAGE向 SCF实体发送推送业务信息， 其中：
Request-URI为 SCF实体的 SIP标识， 用于将 SIP消息路由到 SCF实 体， 可以是 PSI;
P-Preferred-Service头域中包含推送业务标签；
Content-Type为推送业务信息类型； SIP MESSAGE消息体中包含待推送业务信息
MESSAGE sip: bc-scf. iptv.com SIP/2.0
From: <si ： af . iptv. com>; tag=31415
To: <sip:bc-scf.iptv.com>
Accept-Contact: *;+iptv.appid="urn:xxx:iptv.sessionpush'
Content-Type: application/xml
Content-Length: 127
<?xml version:" 1.0" encoding="UTF-8"?>
<IPTVPushActionData
<UserList>sip:user-a@iptv.com</UserList>
<PushContentId>Channel- 1 </PushContentId>
<StartTime>21 :00:00</StartTime>
</IPTVSessionPushActionData >
如果 AF实体提供带切换频道的媒体参数， MESSAGE消息体中也可以 携带相关的媒体参数信息。
SCF实体接收并解析 SIP MESSAGE, 包括：
检测 Accept-Contact头域， 通过推送业务标签确定为推送业务； 检测并解析消息体， 获取推送业务信息， 包括推送用户信息；
SCF实体向 AF实体发送成功响应。
SCF实体根据推送业务标识触发推送业务逻辑， 包括：
根据从推送业务信息中获取的用户标识， 向用户 UE发起推送业务请 求， 这里为 SIP REFER, 其中：
Request-URI为从推送业务信息中获取的用户 SIP标识； Refer-To为推送广告的 SIP标识， 这里包含两个部分， SIP标识中的 user part携带频道标识， 从推送业务信息中获取， SIP标识中的域名部分为 SCF实体的域名；
可以通过 Accept-Contact头域携带推送业务标签， 用于指示 UE该请求 为推送业务请求；
可以通过消息体携带推送内容的媒体参数信息， 此时 Content-Type应该 为 application/sdp。
Core IMS向 UE转发 SIP REFER。
UE处理 SIP REFER, 包括：
如果 REFER通过 P-Preferred-Service携带推送业务标识， UE可以基于 标识触发推送业务逻辑；
UE可以通过 Refer-To头域中 SIP标识的 user part部分获取推送内容标 识；
如果 REFER通过消息体携带了媒体参数， UE可以获取媒体参数。 UE响应 REFER;
UE根据 REFER指示发起业务请求， 完成频道切换。
本实施例中完成会话协商需要获取推送内容的媒体信息， 包括媒体格 式、 带宽信息等， 这些信息可以通过上述实施例中给出的方式， 由业务触发 功能实体获取后通过推送业务请求携带到业务控制功能实体； 也可以由业务 控制功能实体等需要这些信息的实体根据内容标识向保存有这些媒体信息的 功能单元获取等其它方式实现， 这里不再赘述。
实施本发明的实施例， 通过推送业务信息触发推送业务逻辑， 协商完成 推送业务逻辑； 可通过网络侧主动发起会话向用户推送需要的内容； 可以实 现业务通用的推送功能， 后续各种具体的推送业务； 可以有效地提高应用的 部署， 简化网络的复杂度。 通过以上的实施方式的描述， 本领域的技术人员可以清楚地了解到本发 明可借助软件加必需的硬件平台的方式来实现， 当然也可以全部通过硬件来 实施。 基于这样的理解， 本发明的技术方案对背景技术做出贡献的全部或者 部分可以以软件产品的形式体现出来， 该计算机软件产品可以存储在存储介 质中， 如 ROM/RAM、 磁碟、 光盘等， 包括若干指令用以使得一台计算机 设备 （可以是个人计算机， 服务器， 或者网络设备等） 执行本发明各个实施 例或者实施例的某些部分所述的方法。
以上所揭露的仅为本发明的较佳实施例而已， 当然不能以此来限定本发 明之权利范围， 因此依本发明权利要求所作的等同变化， 仍属本发明所涵盖 的范围。

Claims

权利要求书
1、 一种业务推送协商方法， 所述方法应用于网络电视基于多媒体子系 统 IMS Based lPTV网络， 其特征在于， 所述方法包括：
接收推送业务信息， 所述推送业务信息携带推送业务标识；
解析所述推送业务信息；
根据所述推送业务信息触发推送业务逻辑， 发送推送业务请求， 所述推 送业务请求携带推送内容标识；
协商完成所述推送业务逻辑。
2、 如权利要求 1所述的方法， 其特征在于， 所述解析所述推送业务信 息， 包括：
根据所述推送业务标识确定所述推送业务信息为推送业务请求； 获取推送业务接收用户标识信息、 推送业务的推送内容标识、 推送业务 推送时间信息中的任意一种或者任意组合。
3、 如权利要求 1或 2所述的方法， 其特征在于，
通过会话启动协议 SIP消息体或超文本传输协议 HTTP消息体携带所述 推送业务标识时， 通过可扩展标记语言 XML定义所述推送业务标识； 或者 通过 SIP头域携带推送业务标识时， 通过媒体特性标签定义所述推送业 务标识。
4、 如权利要求 2所述的方法， 其特征在于， 所述推送业务接收用户标 识为 IMS公共用户标识 IMPU。
5、 如权利要求 1或 2所述的方法， 其特征在于， 所述推送业务标识包 括频道信息、 节目信息或者内容信息；
所述推送业务信息还包括以下信息的任意一种或者任意组合： 接收推送业务的用户信息；
接收推送业务的用户列表信息；
推送业务开始执行的时间信息； 推送应用相关信息。
6、 如权利要求 5所述的方法， 其特征在于，
所述推送业务信息基于会话描述协议 SDP或 XML定义； 或
通过 SIP消息体或 HTTP消息体携带所述推送业务信息。
7、 如权利要求 5所述的方法， 其特征在于， 所述根据所述推送业务信 息触发推送业务逻辑， 发送推送业务请求， 包括：
获取所述推送业务信息中的接收推送业务的用户信息或者用户列表信 息；
给用户信息中的用户或者用户列表信息中用户列表的用户发送推送业务 请求；
所述推送业务请求为 SIP请求， 所述 SIP请求为 INVITE、 MESSAGE 或 REFER消息。
8、 如权利要求 7所述的方法， 其特征在于，
所述推送业务请求通过 SIP头域或者 SIP消息体携带所述推送业务信息 包括的信息中的任意一种或者任意组合。
9、 一种业务推送协商装置， 所述装置应用于网络电视基于多媒体子系 统 IMS Based lPTV网络， 其特征在于， 所述装置包括：
接收单元， 用于接收推送业务信息， 所述推送业务信息携带推送业务标 识；
解析单元， 用于解析所述接收单元所接收的推送业务信息；
发送单元， 用于根据所述推送业务信息触发推送业务逻辑， 发送推送业 务请求， 所述推送业务请求携带推送内容标识；
协商单元， 用于协商完成所述推送业务逻辑。
10、 如权利要求 9所述的装置， 其特征在于， 所述解析单元包括： 确定单元， 用于根据所述推送业务标识确定所述推送业务信息为推送业 务请求； 获取单元， 用于获取推送业务接收用户标识信息、 推送业务的推送内容 标识、 推送业务推送时间信息三种中的任意一种或者多种。
11、 如权利要求 9或 10所述的装置， 其特征在于， 所述推送业务标识 包括频道信息、 节目信息或者内容信息；
所述推送业务信息还包括以下信息的任意一种或者任意组合： 接收推送业务的用户信息；
接收推送业务的用户列表信息；
推送业务开始执行的时间信息；
推送应用相关信息。
12、 如权利要求 11所述的装置， 其特征在于， 所述业务推送协商装置 在 IMS Based IPTV网络中为业务控制功能实体。
13、 一种业务推送系统， 所述系统应用于网络电视基于多媒体子系统 IMS Based IPTV网络， 其特征在于， 所述系统包括应用功能实体、 业务控 制功能实体和接收功能实体；
所述应用功能实体用于发送推送业务信息给所述业务控制功能实体， 所 述推送业务信息携带推送业务标识；
所述业务控制功能实体用于接收所述应用功能实体发送的推送业务信 息； 并解析所接收的所述推送业务信息； 以及根据所述推送业务信息触发推 送业务逻辑， 发送推送业务请求， 所述推送业务请求包括推送内容标识； 与 所述接收功能实体协商完成所述推送业务逻辑；
所述接收功能实体用于接收所述业务控制功能实体发送的推送业务请 求； 与所述业务控制功能实体协商完成推送业务逻辑。
14、 如权利要求 13所述的系统， 其特征在于，
所述应用功能实体和业务控制功能实体分别是单独的功能实体， 或者是 合设成一个功能实体； 所述应用功能实体和接收功能实体分别是单独的功能实体， 或者是合设 成一个功能实体。
PCT/CN2009/073811 2008-09-10 2009-09-08 业务推送协商方法及装置、推送业务系统 WO2010028589A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200810198463.8 2008-09-10
CN200810198463A CN101674323A (zh) 2008-09-10 2008-09-10 业务推送协商方法及装置、推送业务系统

Publications (1)

Publication Number Publication Date
WO2010028589A1 true WO2010028589A1 (zh) 2010-03-18

Family

ID=42004808

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/073811 WO2010028589A1 (zh) 2008-09-10 2009-09-08 业务推送协商方法及装置、推送业务系统

Country Status (2)

Country Link
CN (1) CN101674323A (zh)
WO (1) WO2010028589A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016004763A1 (zh) * 2014-07-11 2016-01-14 华为技术有限公司 业务推荐方法和具有智能助手的装置
CN112788128A (zh) * 2020-12-31 2021-05-11 青岛海尔科技有限公司 业务信息的推送方法、装置、存储介质及电子装置
CN113709190A (zh) * 2021-10-27 2021-11-26 中兴通讯股份有限公司 业务设置方法和装置、存储介质及电子设备

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103152315A (zh) * 2011-12-06 2013-06-12 中兴通讯股份有限公司 一种广告投放方法、系统及装置
CN103391529B (zh) * 2012-05-07 2018-03-13 中兴通讯股份有限公司 业务推送方法及装置
CN102752315B (zh) * 2012-07-25 2015-03-18 烽火通信科技股份有限公司 一种灵活适应ims系统业务标签的业务解析方法
CN103763342B (zh) * 2013-12-27 2015-09-30 北京集奥聚合网络技术有限公司 基于运营商数据实现ad_exchange用户映射的方法和系统
CN106341735A (zh) * 2015-07-07 2017-01-18 阿里巴巴集团控股有限公司 一种信息推送方法和装置
WO2017007785A1 (en) * 2015-07-07 2017-01-12 Alibaba Group Holding Limited Computerized system and method for pushing information between devices
CN107770234B (zh) * 2016-08-23 2021-11-19 平安科技（深圳）有限公司 消息推送方法和装置
CN107295059B (zh) * 2017-03-07 2020-11-20 创新先进技术有限公司 业务推送量的统计系统及方法
US11419035B2 (en) 2017-11-21 2022-08-16 Telefonaktiebolaget Lm Ericsson (Publ) Method and function for handling traffic for an application
CN110661821A (zh) * 2018-06-28 2020-01-07 山东北邮信息技术产业研究院有限公司 一种消息推送方法及消息推送装置
CN110086797B (zh) * 2019-04-22 2021-05-28 北京开广信息技术有限公司 媒体流的实时接收方法、客户端、计算机设备和存储介质
CN112612960A (zh) * 2020-08-02 2021-04-06 吕维东 基于智能识别和大数据的信息推送方法及信息推送系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1984324A (zh) * 2005-12-16 2007-06-20 腾讯科技（深圳）有限公司 网络电视发布系统、网络电视客户装置以及方法
CN101188735A (zh) * 2006-11-17 2008-05-28 中兴通讯股份有限公司 下一代通信网络中iptv终端节目点播的方法
CN101198018A (zh) * 2007-12-29 2008-06-11 腾讯科技（深圳）有限公司 电视广告业务的实现方法及广告服务器
JP2008153926A (ja) * 2006-12-18 2008-07-03 Alcatel-Lucent Ｉｐｔｖシステムでコンテクストアウェアのローカル広告を提供するためのシステムおよび方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1984324A (zh) * 2005-12-16 2007-06-20 腾讯科技（深圳）有限公司 网络电视发布系统、网络电视客户装置以及方法
CN101188735A (zh) * 2006-11-17 2008-05-28 中兴通讯股份有限公司 下一代通信网络中iptv终端节目点播的方法
JP2008153926A (ja) * 2006-12-18 2008-07-03 Alcatel-Lucent Ｉｐｔｖシステムでコンテクストアウェアのローカル広告を提供するためのシステムおよび方法
CN101198018A (zh) * 2007-12-29 2008-06-11 腾讯科技（深圳）有限公司 电视广告业务的实现方法及广告服务器

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016004763A1 (zh) * 2014-07-11 2016-01-14 华为技术有限公司 业务推荐方法和具有智能助手的装置
US10949477B2 (en) 2014-07-11 2021-03-16 Huawei Technologies Co., Ltd. Service recommendation method and apparatus with intelligent assistant
CN112788128A (zh) * 2020-12-31 2021-05-11 青岛海尔科技有限公司 业务信息的推送方法、装置、存储介质及电子装置
CN113709190A (zh) * 2021-10-27 2021-11-26 中兴通讯股份有限公司 业务设置方法和装置、存储介质及电子设备
WO2023071915A1 (zh) * 2021-10-27 2023-05-04 中兴通讯股份有限公司 业务设置方法和装置、存储介质及电子设备

Also Published As

Publication number Publication date
CN101674323A (zh) 2010-03-17

Similar Documents

Publication Publication Date Title
WO2010028589A1 (zh) 业务推送协商方法及装置、推送业务系统
US8046479B2 (en) Media channel management
EP2241078B1 (en) Method and internet protocol television (iptv) content manager server for iptv servicing
KR101433225B1 (ko) Ｉｍｓ 아키텍쳐 네트워크에서 ｉｐ 텔레비젼 서비스에 액세스하기 위한 시스템
US8307049B2 (en) Method and device for obtaining media description information of IPTV services
CA2726446C (en) A method and a user equipment for reserving bandwidth
US8184002B2 (en) Method and device for receiving emergency event alert
CN101326826B (zh) 网络电视的业务控制方法、系统以及装置
US20090313376A1 (en) Method and apparatuses for establishing a session between a client terminal and a media supply system to transport a unicast media stream over an ip network
US20100235856A1 (en) Method, system, and device for realizing internet protocol television service
JP2012526411A (ja) セッションプッシュ伝送
WO2009052762A1 (fr) Procédé, dispositif et système d&#39;amélioration de service de diffusion (bc)
WO2007098682A1 (fr) Procédé permettant d&#39;obtenir un guide de programmes électronique, système pour guide de programmes électronique et unité de mise en service
WO2010012165A1 (zh) 接收紧急事件通知的方法、装置和系统
Riede et al. Session and media signaling for IPTV via IMS
WO2008154849A1 (fr) Procédé et entité de fonction pour récupérer les informations de sélection du service iptv
EP2288108B1 (en) Method and network equipment for establishing individualized content delivery channel
CN101483532B (zh) 一种媒体流复制的方法、系统及设备
EP2296377A1 (en) Method, apparatus and system for content switching in content on demand
WO2009024053A1 (fr) Procédé et système pour transférer un message de découverte d&#39;opération et entité fonctionnelle pour une découverte d&#39;opération
WO2010012233A1 (zh) 一种交互信息的传送方法、系统和装置
WO2009135405A1 (zh) 电子节目菜单生成和获取方法、设备及系统
Al-Hezmi et al. Evolving the Convergence of Telecommunication and TV Services over NGN
WO2008052484A1 (fr) Procédé, système et appareil de commande service tv ip
WO2011000151A1 (zh) 网络电视频道业务实现方法和相关设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09812655

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09812655

Country of ref document: EP

Kind code of ref document: A1