WO2009024053A1 - Procédé et système pour transférer un message de découverte d'opération et entité fonctionnelle pour une découverte d'opération - Google Patents

Procédé et système pour transférer un message de découverte d'opération et entité fonctionnelle pour une découverte d'opération Download PDF

Info

Publication number
WO2009024053A1
WO2009024053A1 PCT/CN2008/071909 CN2008071909W WO2009024053A1 WO 2009024053 A1 WO2009024053 A1 WO 2009024053A1 CN 2008071909 W CN2008071909 W CN 2008071909W WO 2009024053 A1 WO2009024053 A1 WO 2009024053A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
service discovery
terminal
discovery information
service
Prior art date
Application number
PCT/CN2008/071909
Other languages
English (en)
French (fr)
Inventor
Youying Li
Jun Yan
Feng Wang
Original Assignee
Huawei Technologies Co., Ltd.
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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2009024053A1 publication Critical patent/WO2009024053A1/zh

Links

Classifications

    • 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/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • 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]

Definitions

  • the present invention relates to data transmission technologies in the field of communications, and in particular, to a method and system for transmitting service discovery information and a service discovery function entity. Background technique
  • Streaming media services or Internet Protocol Television (IPTV) services are a new type of business that has developed rapidly in recent years.
  • Streaming media services use streaming technology to transfer multimedia files, including video, audio, and other files, over a packet-switched network. The contents of these files can be played immediately without having to download them completely.
  • the service system When implementing a streaming media service or an IPTV service, the service system generally needs to provide the user with a functional entity for providing service discovery information to the user, and the functional entity can provide the available IPTV service information to the user, including for accessibility.
  • the information of the IPTV service provider, electronic program navigation (EPG), video on demand navigation (COD Catalogue), etc. also provides entry information of functional entities of streaming media or IPTV service list information.
  • Session Initiation Protocol is one of the multimedia communication system framework protocols developed by the Internet Engineering Task Force (IETF). It is an application layer protocol for establishing, changing or ending multimedia sessions, and real-time transport protocol/real-time. Protocols such as Control Protocol (RTP/RTCP), Service Data Point (SDP), Area Signaling Transfer Point (RTSP), and Network Directory Service (DNS) cooperate to complete session establishment and media negotiation in IMS. Once the session is established, the media stream will be transmitted directly in the bearer layer using the RTP protocol, allowing flexible interaction of multiple media in a single session.
  • RTP Control Protocol
  • SDP Service Data Point
  • RTSP Area Signaling Transfer Point
  • DNS Network Directory Service
  • SIP support includes application layer mobility functions such as dynamic registration mechanism, location management mechanism, and redirection mechanism, as well as presence/fork/subscribe (Presence/Fork/Subscribe) features, which facilitates the expansion of new services, and the protocol is simple and has recognized potential for expansion. Therefore, more and more applications including IP Multimedia Subsystem (IMS) and Next Generation Network (NGN) have been obtained.
  • IMS IP Multimedia Subsystem
  • NPN Next Generation Network
  • IMS introduces SIP protocol as a service control protocol, using SIP to be simple, easy to expand, and media combination
  • the feature of the device is to provide rich multimedia services by separating the service control from the bearer control.
  • the main functional entities in IMS include: Call Control Entity (CSCF) that controls user registration, session control, etc., Application Server (AS) that provides various business logic control functions, and Home Subscriber Server (HSS) that centrally manages user subscription data.
  • CSCF Call Control Entity
  • AS Application Server
  • HSS Home Subscriber Server
  • MGCF / IM-MGW media gateway for implementing interworking with the circuit switched network, the user accessing the IMS through the current local proxy node (P-CSCF), session and service trigger control, and interaction with the service control of the AS
  • S-CSCF home domain service node
  • IMS based IPTV provides IPTV services under the overall architecture of IMS to take full advantage of the existing registration, authentication, routing, session control and establishment, service triggering, charging, and end-to-end quality of service (QoS) guarantees in the IMS network.
  • QoS quality of service
  • FIG. 1 a schematic diagram of a service function architecture of an IMS-based IPTV (IMS-based IPTV) defined for a standard organization ETSI TISPAN, wherein a Service Discovery Function Entity (SDF) can send a service to a User Terminal (UE) through an IMS network
  • SDF Service Discovery Function Entity
  • the discovery information includes the entry address of the service selection function entity (SSF) and the like.
  • Business selection information can be obtained through SSF, including: EPG information or CoD Catalogue information.
  • FIG. 2 a schematic diagram of a signaling flow for transmitting service discovery information to a UE for an SDF, where the SDF determines that the UE accesses the IMS network, selects an SSF for performing the service, and passes the selected SSF entry information.
  • the Core IMS sends the UE to the UE.
  • the process of sending the service discovery information to the UE by the SDF is implemented.
  • the UE obtains service selection information from the SSF according to the obtained service discovery information.
  • the embodiments of the present invention provide a method and a system for transmitting service discovery information, and a service discovery function entity, which solves the problem that the SDF cannot transmit the service discovery information to the UE in a flexible manner.
  • a method of delivering business discovery information comprising:
  • the service discovery function entity determines that the terminal accesses the IP multimedia subsystem
  • the service discovery function entity delivers service discovery information to the terminal through a message method (MESSAGE) in a Session Initiation Protocol (SIP) or a publish method in a session initiation protocol (PUBLISH), or establishes a message session with the terminal. After the protocol (MSRP) session, the service discovery information is delivered to the terminal through the established session.
  • MESSAGE message method
  • SIP Session Initiation Protocol
  • PBLISH session initiation protocol
  • MSRP session a session initiation protocol
  • a system for transmitting service discovery information includes a terminal and a service discovery function entity, where the terminal includes:
  • An access module configured to access an IP multimedia subsystem
  • a receiving module configured to receive service discovery information
  • the service discovery function entity includes:
  • a determining module configured to determine whether the terminal accesses an IP multimedia subsystem
  • a delivery module configured to: when the result of the determining module is that the terminal accesses the IP multimedia subsystem, transmit the service discovery information to the terminal by using a message method in a session initiation protocol or a publishing method in a session initiation protocol, or After the session session relay protocol session is established between the terminals, the service discovery information is delivered to the terminal through the established session.
  • a business discovery functional entity comprising:
  • a determining module configured to determine whether the terminal accesses an IP multimedia subsystem
  • a delivery module configured to: when the determining module obtains the result that the terminal accesses the IP multimedia subsystem, transmitting the service discovery information to the terminal by using a message method in a session initiation protocol or a publishing method in a session initiation protocol After establishing a message session relay protocol session with the terminal, the service discovery information is delivered to the terminal through the established session.
  • the session is sent by using the session.
  • the method of transmitting the service discovery information to the terminal through the established session not only implements the process of transmitting the service discovery information to the UE by the SDF in the IMS, but further makes the process of transmitting the service discovery information more flexible and convenient.
  • FIG. 1 is a schematic diagram of a service function architecture of an IMS-based IPTV in the background art
  • FIG. 2 is a schematic diagram of a signal flow of a service discovery function entity transmitting service discovery information to a user terminal in the background art
  • FIG. 3 is a schematic structural diagram of a system for transmitting service discovery information according to Embodiment 1 of the present invention
  • FIG. 4 is a schematic flowchart of a method for transmitting service discovery information according to Embodiment 2 of the present invention
  • FIG. 6 is a schematic flowchart of a signaling process for transmitting service discovery information by using a publishing method in SIP according to Embodiment 4 of the present invention
  • Figure ⁇ is a schematic diagram of a signaling process of a process in which a UE initiates a message session relay protocol session establishment request to implement service discovery information transmission according to Embodiment 5 of the present invention
  • FIG. 8 is a schematic diagram of a signaling flow of a process of initiating a message session relay protocol session establishment request by a service discovery function entity to implement service discovery information transmission according to Embodiment 6 of the present invention
  • FIG. 9 is a schematic structural diagram of a service discovery function entity in Embodiment 7 of the present invention. detailed description
  • the protocol in the SIP protocol is simple, the performance is good, and the flexibility is good, and the message method (SIP MESSAGE) in the SIP protocol is proposed, and the SIP PUBLISH is issued. ) or establish a message session relay association with the UE
  • MSRP service discovery information
  • FIG. 3 it is a schematic structural diagram of a system for transmitting service discovery information according to Embodiment 1 of the present invention. It can be seen from the figure that the system includes a terminal 11 and a service discovery function entity 12.
  • the terminal 11 includes an access module 21 and a receiving module 22, wherein the access module 21 is configured to access an IP multimedia subsystem, and the receiving module 22 is configured to receive service discovery information.
  • the service discovery function entity 12 includes a determination module 31 and a delivery module 32, wherein the determination module 31 is configured to determine whether the terminal 11 is connected to the IP multimedia subsystem; and the delivery module 32 is configured to: when the result of the determination module 31 is obtained as a terminal connection
  • the service discovery information is transmitted to the terminal through the SIP MESSAGE or the SIP PUBLISH, or the service discovery information is transmitted to the terminal 11 through the established session after the MSRP session is established with the terminal.
  • the working process between the terminal 11 and the service discovery function entity 12 is: after the determining module 31 learns that the access module 21 successfully accesses the IMS, the instructing delivery module 32 transmits the service discovery information to the receiving module 22.
  • the terminal 11 may further include an obtaining module 23, configured to obtain the service selection information according to the media stream address in the service discovery information or the portal information provided by the unified resource identifier.
  • the service discovery information is IPTV service discovery information.
  • the second embodiment of the present invention further provides a method for implementing delivery service discovery information. As shown in FIG. 4, the method includes:
  • Step 401 The SDF determines that the UE accesses the IMS network.
  • the UE After the UE completes the network attachment, it initiates a standard IMS registration process and successfully accesses the IMS network.
  • the SDF needs to know that the UE successfully accesses the IMS. There are various methods, including but not limited to: 1. After the UE accesses the IMS, the UE sends a request for service discovery information to the SDF. When the SDF receives the request, the default terminal. Successfully accessed IMS; 2. The SDF subscribes to the status information of the UE to the status server (Presence Server, PS). After the UE successfully accesses the IMS, the PS sends the status information of the successful access to the SDF.
  • the SDF subscribes to the status information of the UE to the status server (Presence Server, PS).
  • the S-CSCF After the UE accesses the IMS, the S-CSCF sends a third-party registration request to the SDF, and determines that the terminal accesses the IP multimedia subsystem.
  • Step 402 The SDF will deliver the service discovery information to the UE through the SIP protocol.
  • the SDF transmits the service discovery information to the UE through the SIP protocol, including but not limited to: SDF delivers service discovery information through SIP MESSAGE, SDF delivers service discovery information through SIP PUBLISH, or SDF establishes message session relay protocol (MSRP) through negotiation to deliver service discovery. information.
  • SDF delivers service discovery information through SIP MESSAGE
  • SDF delivers service discovery information through SIP PUBLISH
  • MSRP message session relay protocol
  • the service discovery information includes a version number, a status, and service provider information.
  • the version number information describes the version number of the service discovery information that the SDF delivers to the UE. According to the version number information, it can be determined whether the service discovery information needs to be updated.
  • the status information describes the service delivered by the SDF.
  • the discovery information contains all the business discovery information or only the updated information. If the service discovery information described in the status information includes only the updated information, when the service discovery information needs to be updated according to the version number, the information transmitted by the SDF may include only the updated information.
  • the service provider's information includes the domain name, the logo entry (LogoURI), the version number, and the load information ( Offering ).
  • the domain name can uniquely identify the service provider, and the LogoURI can provide the logo information of the service provider.
  • the version number information is different from the foregoing, and is a version of the service discovery information of the service provider that describes the domain name identifier.
  • the Distribution contains the load identifier, version number, and service entry address information.
  • the load identifier is used to identify the type of service information that can be further obtained, for example, the service selection information, including all the information, or only the EPG information and/or the CoD Catalogue information.
  • the version number describes the version number of the load information.
  • the service entry address information describes an entry address for further obtaining the service information, and the terminal may obtain the entry address of the service information according to the service entry address information. For example, if the entry address provides the service selection information, the terminal may obtain the service selection information by using the entry address. If The service address information is provided by the entry address, and the terminal can obtain the service key information through the entry address.
  • Different types of service entry addresses need to be provided according to different service information, including but not limited to: media stream form (Stream) or uniform resource identifier form (URI).
  • the service discovery information includes the stream type information, and provides the media stream address/port information to the UE, and the UE further obtains service information, such as service selection information, according to the information.
  • the address information here is a multicast address, and the UE may further join the multicast group to obtain service information.
  • the service discovery information includes URI type information, and provides URI information to the UE, and the UE further obtains the service information according to the URI information.
  • targetNamespace n um:xxxx:params:xml:ns:servicediscoveryinfo"
  • Version is the version number of the service discovery information
  • State is the status information of the service discovery information, indicating whether the service discovery information contains all the service discovery information or only part of the service discovery information */ ⁇ xs:simpleType>
  • This group is the attribute of the service provider information, including the DomainType that uniquely identifies the service provider, the LogoURI of the logo, and the version number of the service provider information (Version) */ ⁇ /xs:complexType>
  • ServiceProviderInfo including the version number of the service provider ServiceProviderInfo, and the payload type (Payload-ID).
  • the payload type determines what information the service provider can provide, at least including providing all the information.
  • the load portion of the service discovery information can directly carry services such as service selection information.
  • Information not entry address information.
  • the following describes the second embodiment in detail by taking the SIP MESSAGE, the SIP PUBLISH, and the MSRP connection and transmitting the service discovery information as an example.
  • FIG. 5 it is a schematic diagram of a signaling process for transmitting service discovery information by using a SIP MESSAGE according to the third embodiment of the present invention.
  • the third embodiment includes the following steps:
  • Step 501 The UE successfully accesses the IMS network.
  • the method for the UE to access the IMS network includes but is not limited to: after the UE initiates and completes the network attachment, an IMS registration process is initiated.
  • SIP REGISTER third-party registration request
  • the S-CSCF in the IMS obtains the user subscription information of the UE from the user subscription service function entity (UPSF).
  • UPSF user subscription service function entity
  • the S-CSCF in the IMS sends a SIP REGISTER.
  • Step 503 The SDF responds to the SIP REGISTER, and returns a success response message (SIP 200 ⁇ ).
  • the SDF determines that the UE has successfully accessed the IMS.
  • Step 504 The SDF sends the IPTV service discovery information to the UE by using a SIP MESSAGE message.
  • the IPTV service discovery information includes, but is not limited to, part or all of the content described in Table 1, and the IPTV service discovery information may be carried by a message body in the SIP MESSAGE.
  • the IPTV service discovery information is carried in each part of the SIP MESSAGE message: the Request URI carries information such as the SIP URI or IP address of the UE that receives the IPTV service discovery information; and the From header field carries the service discovery function (SDF). Information such as SIP URI or IP address; To header field is information such as SIP URI or IP address of UE receiving the IPTV service discovery information; Content-Type header field carries defined application/sd+xml; message body carries specific IPTV Service discovery information, which is sent in the form of application/sd+xml.
  • SDF service discovery function
  • SIP MESSAGE message body The specific description of the SIP MESSAGE message body can be as follows:
  • Xmlns:xsi http://www.w3.org/200 l/XMLSchema-instance
  • Xsi:schemaLocation urn:xxxx:params:xml:ns:sdinfo ⁇ SD.xml
  • PayLoad-ID indicates the type of information that the IPTV service discovery information provides for the portal.
  • the information may be EPG, CoD Catalogue, etc., "All" indicates All types.
  • the user terminal can determine the information that can be obtained based on the acquired load type. */
  • This Offering-Stream indicates that the portal information is streaming address information.
  • the terminal can further acquire related information in the form of streaming media through the address.
  • ⁇ Offering-URI UI http://sp2.iptv.com//epg/"/>/> /*
  • the providing-URI indicates that the ingress address is a URI type, and the user terminal can further obtain related service information through the URI.
  • the UE After receiving the IPTV service discovery information sent by the SDF, the UE may further obtain related service information according to the service discovery information.
  • the service discovery information includes an entry address of the service selection information, and the terminal may obtain the service selection information according to the entry information.
  • the fourth embodiment of the present invention transmits service discovery information through SIP PUBLISH.
  • the process is as shown in FIG. 6, and includes:
  • Step 601 The SDF determines that the state of the UE is successful access to the IMS.
  • the determining process may include:
  • SDF subscribes to the status information of the UE. After the UE subscribes to the IPTV service, the SDF subscribes to the UE status to the PS through a standard subscription/notification (IMS SUBSCRIBE/NOTIFY) mechanism. In addition, the user status can also be managed by the SDF itself.
  • IMS SUBSCRIBE/NOTIFY standard subscription/notification
  • the UE initiates and completes network attachment.
  • the UE initiates the IMS registration process.
  • the UE advertises its own state information to the PS, and the state information may be information such as the UE going online.
  • the UE may issue status information through IMS PUBLISH, or may issue status information through the network entity proxy itself.
  • the PS notifies the status of the UE to the SDF, and the SDF can determine the status of the UE in real time.
  • the SDF can determine the status of the UE in real time.
  • the UE is determined to access the IMS.
  • Step 602 The SDF sends an IPTV service discovery message to the UE by using a SIP PUBLISH message, where the message is carried by the message body.
  • the service discovery information may be the selection information of the SSF, and the related information may be sent in a customized application/sd+xml format, where the related information includes but is not limited to: Description information of the IPTV service provider, and entry address information of the SSF.
  • each part of the SIP PUBLISH message carries the IPTV service discovery information: the Request URI carries information such as the SIP URI or IP address of the UE that receives the IPTV service discovery information; and the From header field carries the SIP URI or IP address of the SDF.
  • the To header field is information such as the SIP URI or IP address of the UE that receives the IPTV service discovery information; the Content-Type header field carries the defined application/sd+xml; and the Event header field indicates that the transmitted information is the service discovery information.
  • the message body carries specific IPTV service discovery information, including but not limited to some and all of the content described in Table 1.
  • PayLoad-ID indicates the load type of IPTV service discovery information, including
  • Offering-Stream indicates that the ingress information is a streaming multicast address.
  • “sd-information” is a newly defined object (Event), and you can also use an existing Event.
  • “application/sd+xml” is a newly defined Content-Type for carrying IPTV service selection information.
  • the fifth embodiment and the sixth embodiment of the present invention transmit service discovery information after establishing a session through MSRP negotiation.
  • the MSRP is a text-based, connection-oriented transmission protocol formulated by the IETF, and can be used for exchanging arbitrary (including binary) multi-purpose. Multipurpose Internet Mail Extensions (MIME) content, especially for instant messaging.
  • MIME Multipurpose Internet Mail Extensions
  • MSRP negotiates to establish a message session through SIP and SDP.
  • MSRP When applying MSRP, you need to negotiate the media attributes to be transmitted between the source and destination. This negotiation process can be carried and sent by SIP and SDP signaling, and then The port number and media attributes are used to transfer media data.
  • the media data type supported by MSRP is any data in MIME format, such as text, audio, video, and so on.
  • the SDP carries the MSRP media information to negotiate between the UE and the SDF through the Offer/Answer Model.
  • the negotiation is successful, the MSRP session is established, and then the IPTV service discovery information is performed through the MSRP protocol. Transfer.
  • the fifth embodiment of the present invention is a process of initiating an MSRP session establishment request by the UE to implement service discovery information transmission.
  • the specific process is as shown in FIG. 7, and includes:
  • Step 701 The UE sends a SIP INVITE request to the SDF through the IMS.
  • the UE completes the network attachment and registers successfully in the IMS.
  • the UE sends a SIP INVITE request to the Core IMS, and the Core IMS forwards the SIP INVITE request to the SDF.
  • the UE sends a SIP INVITE request to the SDF for negotiating to establish an MSRP session.
  • the Request URI in the SIP INVITE request carries information such as the SIP URI or IP address of the SDF.
  • the information can be obtained through pre-configuration or DHCP.
  • the PSI is used to identify the SDF. Therefore, the SIP INVITE request can be sent to the SDF through the PSI routing method.
  • the initial filtering rule (iFC) triggering method can also be used to implement the routing.
  • the UE sends the MSRP media information to the SDF through the SDP, and performs media negotiation with the SDF.
  • the MSRP media information of the UE includes:
  • the SDP media line (Media Line, m), which carries information about the media, such as transmission information.
  • the media type is message
  • the port is the port number for the UE to receive service discovery information.
  • MSRP is carried on the transmission control protocol (MSRP over TCP)
  • the protocol is TCP/MSRP
  • the MSRP media information of the foregoing UE is sent by using a SIP INVITE request.
  • Step 702 The SDF sends its own MSRP media information to the UE.
  • the SDF After receiving the SIP INVITE request sent by the UE, the SDF obtains the MSRP media information carried in the SDP, and carries its own MSRP media information in the SDP, and sends the information to the UE through the SIP 200 OK message.
  • the MSRP media information of the SDF itself includes:
  • the SDP media line carries the media information.
  • the difference from the SDP media line information sent by the UE is that the port is the port number of the SDF.
  • the SDP attribute line including path and content type, where path indicates the transmission path of the message and contains the address information of the SDF; the content type indicates the type of the message transmission, that is, the defined application/sd+xml, for example:
  • Step 703 The UE completes MSRP negotiation with the SDF, and establishes an MSRP session and a transmission channel.
  • Step 704 The SDF delivers the IPTV service discovery information to the UE through the established MSRP session and the transmission channel.
  • the SDF sends the IPTV service discovery information to the UE through the MSRP SEND message, and the IPTV service discovery information is the available IPTV service information, and the information is sent by using the defined application/sd+xml form, and the information may include but not Limited to some or all of the content described in Table 1.
  • Step 705 After receiving the IPTV service discovery information, the UE returns an acknowledgement message to the SDF.
  • FIG. 8 is a schematic diagram of a process for transmitting an MSRP session establishment request by an SDF to deliver service discovery information according to Embodiment 6 of the present invention.
  • the process may be as follows:
  • Step 801 After the SDF determines that the UE successfully accesses the IMS, sends a SIP INVITE request to the UE.
  • This step includes:
  • the UE initiates and completes network attachment.
  • the UE initiates the IMS registration process and successfully registers with the IMS.
  • the S-CSCF obtains the public user identity in the registration process, and determines the iFC that the public user identity matches.
  • the S-CSCF initiates a third party registration request (SIP REGISTER) to the SDF, and includes the above public user identity in the "To:" header field of the SIP REGISTER.
  • SIP REGISTER third party registration request
  • the SDF returns a SIP 200 OK message to the S-CSCF in response to the SIP REGISTER message. 6.
  • the SDF forwards the SIP INVITE request to the UE through the Core IMS, and is used to establish an MSRP session with the UE to transmit the IPTV service discovery information.
  • the PSI is used to identify the SDF. Therefore, the process of transmitting the SIP INVITE request may be an IMS AS initial call procedure, that is, a PSI-to-user routing process.
  • the Request URI in the SIP INVITE request sent by the SDF to the UE carries information such as the SIP URI or IP address of the UE.
  • the SDF can be obtained through third-party registration or pre-configuration.
  • the SDF obtains the MSRP media information in the SDP, and carries the MSRP media information in the SDP, and sends the information to the UE through the SIP INVITE request.
  • the MSRP media information of the SDF itself includes:
  • Step 802 The UE sends its own MSRP media information to the SDF.
  • the UE sends the SIP 200 OK information including its own MSRP media information to the Core IMS.
  • the core IMS forwards the SIP 200 OK information to the SDF.
  • the MSRP media information of the UE includes:
  • Step 803 Perform MSRP negotiation between the UE and the SDF to establish an MSRP session and a transmission channel.
  • Step 804 The SDF delivers the IPTV service discovery information to the UE through the established MSRP session and the transmission channel.
  • the SDF sends the IPTV service discovery information to the UE through the MSRP SEND message, and the IPTV service discovery information is carried by the message body.
  • IPTV service discovery information is available IPTV service information, and the information is sent in the form of a defined application/sd+xml, which may include, but is not limited to, some or all of the contents described in Table 1.
  • This process is different from the To-Path and From-Path paths in the fifth embodiment.
  • Step 805 After receiving the IPTV service discovery information, the UE returns an MSRP 200 OK to the SDF.
  • the UE may obtain service entry information by using information such as stream or URI in the IPTV service discovery information, and further obtain service selection information. Based on different service discovery information, the UE may obtain service selection information in different manners:
  • the UE can obtain the IPTV service selection information by using the obtained address information. For example, when the service selection information is sent in the form of multicast, the user terminal joins the multicast group according to the obtained multicast address. Obtain IPTV service selection information, such as IGMP Join.
  • the portal information is a URI
  • the following conditions are included:
  • the UE may obtain the IPTV service selection information through a protocol such as HTTP.
  • a protocol such as HTTP.
  • the UE can obtain the IPTV through the MSRP protocol.
  • the service selection information, the MSRP session negotiation is similar to the MSRP session negotiation for obtaining the IPTV service discovery information.
  • the SDF may transmit the service discovery information to the UE multiple times.
  • the service discovery information transmitted by the SDF may be different.
  • the SDF transmits the service discovery information to be delivered to the UE, or the SDF compares the change between the current service discovery information to be delivered and the previous service discovery information.
  • the changed information is passed to the UE.
  • the latter case can be applied to processes such as data upgrades.
  • the service discovery information that is transmitted twice is compared with the version identifier of the service identifier.
  • the service discovery information to be delivered is determined.
  • the information corresponding to the version identifier is delivered to the UE.
  • the comparison basis is not limited, and other contents in the service discovery information may be compared.
  • the MSRP session connection between the SDF and the UE may be retained or released. If the IPTV service discovery information needs to be updated, the SDF can use the MSRP SEND message to deliver the update message to the UE; if the session connection has been released, the MSRP session can be re-established according to the fifth embodiment or the sixth embodiment. connection.
  • the SDF can select appropriate service discovery information for the UE before transmitting the IPTV service discovery information to the UE, for example, selecting an appropriate SSF, and implementing customized service discovery information according to the subscription information of the user.
  • the SDF can select an appropriate SSF according to the location information, capabilities, and subscription information of the UE, for example:
  • the SDF first obtains the location information of the UE, and uses the SSF of the UE as the appropriate SSF, that is, the IPTV service discovery information of the location selected by the UE, and therefore, the IPTV service discovery received by the UE.
  • the information includes the current location of the IPTV service provider.
  • SDF can obtain user terminal location information in a variety of ways, such as from a Location Server.
  • User subscription data can include:
  • Personalized/Customized Business Discovery Contract Information which will be personalized/customized as an additional service, which identifies whether the user has signed up for personalized/customized business discovery information
  • language information that is, the language information signed by the user, can determine which service discovery information is delivered according to the language information of the user;
  • the IPTV service may be provided by multiple SPs, and the user may sign one or more of them;
  • Customized service discovery information for example: Is it providing discovery information of all SPs, or only providing partial SP discovery information; is it providing all service discovery information for the SP, or only providing partial information of each SP, such as Ingress address, etc., without the description information of the SP, etc.;
  • the service discovery information delivery method describes the conditions for delivering the service discovery information, for example, when the data is sent periodically or when the data is updated;
  • the business discovery information provided for the user for example, the commonly used SP information is provided in an eye-catching manner.
  • This information may be provided dynamically and may be provided by the relevant functional entity.
  • the IPTV service discovery information transmitted by the SDF to the terminal includes only ⁇ 861 ⁇ whose attribute is "CoD Catalogue". 6?1"( ⁇ (161"11 ⁇ 0>, or only the service information of the attribute "CoD Catalogue" in ⁇ ServiceProviderInfo> is provided.
  • SDF can obtain user subscription information in various ways, for example, SDF saves the management user subscription information by itself.
  • the SDF obtains the user subscription information from the network entity UPSF, or the SDF obtains the user subscription information from other network entities that store the user subscription information.
  • the terminal capabilities may include: user terminal device types (eg, model number, version number (identifying user terminal client software version)), and user terminal device capabilities (screen size, resolution, codec capability, and support protocol).
  • user terminal device types eg, model number, version number (identifying user terminal client software version)
  • user terminal device capabilities screen size, resolution, codec capability, and support protocol.
  • Personalized service discovery information can be provided to users according to user terminal capabilities. For example, if the user's terminal only supports the SD format, the SDF can filter out the information of the Service Provider that only provides the HD format program.
  • the SDF can obtain the terminal capability in multiple ways.
  • the SDF obtains the terminal capability from the terminal.
  • the user terminal carries the terminal capability to the SDF when registering; or the functional entity acquires and manages the user terminal capability in the network, and the SDF obtains the corresponding function from the functional entity.
  • User terminal capabilities For example, the user terminal carries the terminal capability to the SDF when registering; or the functional entity acquires and manages the user terminal capability in the network, and the SDF obtains the corresponding function from the functional entity.
  • the SDF selects the SSF to determine the service discovery information to be delivered.
  • the SDF may also provide information of other functional entities, such as security protection function entity information, according to the request of the terminal.
  • the seventh embodiment of the present invention is an SDF.
  • the method includes: a determining module 41 and a transmitting module 42, where the determining module 41 is configured to determine the terminal. Whether to access the IP multimedia subsystem; the delivery module 42 is configured to: when the determining module obtains the result that the terminal accesses the IP multimedia subsystem, deliver the service discovery information to the terminal by using SIP MESSAGE or SIP PUBLISH, or After the MSRP session is established with the terminal, the service discovery information is delivered to the terminal through the established session.
  • the delivery module 42 includes a comparison unit 51 and a execution unit 52, wherein the comparison unit 51 is configured to compare the service discovery information to be delivered with the service discovery information that was previously delivered; the execution unit 52 is configured to determine the comparison unit 51. The changed information is passed to the terminal.
  • the comparison unit 51 is configured to compare the service discovery information to be delivered with the version identifier of the service discovery information that was previously delivered; the execution unit 52 is configured to: when the version identifier changes, the service to be delivered The information corresponding to the version identifier of the discovery information is delivered to the terminal.
  • the setup unit and the operation unit are included, where the setup unit is configured to initiate an MSRP session establishment request to the terminal, or receive the terminal.
  • An initiated MSRP session establishment request; the operation unit is configured to establish an MSRP session according to the session establishment request, and deliver the service discovery information to the terminal through the established session.
  • the SDF transmits service discovery information by means of SIP MESSAGE, SIP PUBLISH, MSRP SEND, etc., and may also use other messaging service discovery information, such as SIP information method (INFO), SIP subscription/notification (SUBSCRIBE/ NOTIFY), etc., will not be detailed here.
  • SIP information method INFO
  • SIP subscription/notification SUBSCRIBE/ NOTIFY
  • the system and method provided by the embodiments of the present invention enable the SDF to transmit the IPTV service discovery information to the UE more flexible and simple, and provide multiple information update methods to simplify user operations.
  • the SDF can personally select the SSF.
  • the transmitted IPTV service discovery information is more reliable, and the user body 3 is all better.

Landscapes

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

Description

传递业务发现信息的方法、 系统及业务发现功能实体
技术领域
本发明涉及通信领域的数据传输技术， 尤其涉及一种传递业务发现信息 的方法、 系统及一种业务发现功能实体。 背景技术
流媒体业务或因特网协议电视（IPTV )业务是近几年迅速发展的一种新 业务。 流媒体业务利用流式传输技术， 在包交换网络上传输多媒体文件， 包 括视频、 音频等文件。 这些文件中的内容在访问时无需完全下载就可以立即 播放。 在实施流媒体业务或 IPTV业务时， 业务系统一般需要向用户提供一个 用于向用户提供业务发现信息的功能实体， 该功能实体可以向用户提供可用 的 IPTV业务信息， 包括用于可以接入的 IPTV业务提供者的信息， 电子节目导 航（EPG ), 视频点播导航 ( CoD Catalogue )等， 还提供流媒体或 IPTV业务 列表信息的功能实体的入口信息等。
会话发起协议 ( Session Initiation Protocol, SIP )是由 Internet工程任务组 ( IETF )制订的多媒体通信系统框架协议之一， 是用于建立、 改变或结束多 媒体会话的应用层协议， 与实时传输协议 /实时控制协议（RTP/RTCP )、 业务 数据点 ( SDP )、 区域信令转换点 (RTSP)和网络目录服务 ( DNS )等协议配合， 共同完成 IMS中的会话建立及媒体协商。 一旦建立会话， 媒体流将使用 RTP 协议在承载层中直接传送， 在一次会话中可以灵活的交互多种媒体。
SIP支持包括动态注册机制、 位置管理机制、 重定向机制等应用层移动性 功能以及呈现 /分叉 /订阅 （Presence/Fork/Subscribe )特性， 便于扩展新业务， 而且协议简单， 具有公认的扩展潜力， 因此获得了包括在 IP多媒体子系统 ( IMS )及下一代网络（NGN ) 中的越来越多的应用。
IMS引入 SIP协议作为业务控制协议， 利用 SIP简单、 易扩展、媒体组合方 便的特点， 通过将业务控制与承载控制分离， 提供丰富的多媒体业务。 IMS 中主要的功能实体包括： 控制用户注册、 会话控制等功能的呼叫控制实体 ( CSCF ) 、 提供各种业务逻辑控制功能的应用服务器 ( AS ) 、 集中管理用 户签约数据的归属用户服务器（HSS ) 以及用于实现与电路交换网互通的媒 体网关（ MGCF / IM-MGW ) , 用户通过当前所在地代理节点 （ P-CSCF )接 入 IMS , 会话和业务触发控制及与 AS的业务控制交互则由其注册地的归属域 服务节点 （ S-CSCF ) 完成。
IMS based IPTV就是在 IMS的整体架构下提供 IPTV业务， 以充分利用 IMS 网络中已有的注册、 认证、 路由、 会话控制与建立、 业务触发、 计费、 端到端服务质量（QoS )保证等机制来为用户提供流媒体业务及融合流媒体 和实时会话业务的多媒体业务。
如图 1所示， 为标准组织 ETSI TISPAN定义的基于 IMS的 IPTV ( IMS based IPTV )的业务功能构架的示意图， 其中， 业务发现功能实体（ SDF )可 以通过 IMS网络向用户终端（UE )发送业务发现信息， 该业务发现信息包括 业务选择功能实体（SSF )的入口地址等。 通过 SSF可以获得业务选择信息， 包括： EPG信息或 CoD Catalogue信息等。
如图 2所示， 为 SDF向 UE发送业务发现信息的信令流程示意图， 从图 中可以， SDF确定 UE接入 IMS网络后， 选择执行业务的 SSF , 并将选择出 的 SSF的入口信息通过 Core IMS发送给 UE , 此时， 实现了 SDF向 UE发送 业务发现信息的过程。 进一步地， UE根据获得的业务发现信息从 SSF处获 取业务选择信息。
目前的实现传递业务发现信息的方案大都不够灵活、 简便， 而我们迫切 需要一种既简单， 又扩展性能好和灵活性好的实现 SDF向 UE传递业务发现 信息的方法。 发明内容 本发明实施例提供一种传递业务发现信息的方法、 系统及一种业务发现 功能实体， 以解决现有技术中存在的不能够实现灵活、 简便地实现 SDF 向 UE传递业务发现信息的问题。
一种传递业务发现信息的方法， 该方法包括：
业务发现功能实体确定终端接入 IP多媒体子系统；
所述业务发现功能实体通过会话发起协议 （ SIP ) 中的消息方法 ( MESSAGE )或会话发起协议中的发布方法 （PUBLISH )将业务发现信息 传递给所述终端， 或与终端之间建立消息会话中继协议（MSRP )会话后， 通 过建立的会话将业务发现信息传递给所述终端。
一种传递业务发现信息的系统， 该系统包括终端和业务发现功能实体， 其中， 所述终端包括：
接入模块， 用于接入 IP多媒体子系统；
接收模块， 用于接收业务发现信息；
所述业务发现功能实体包括：
确定模块， 用于确定所述终端是否接入 IP多媒体子系统；
传递模块， 用于当所述确定模块的结果为终端接入 IP多媒体子系统时， 通过会话发起协议中的消息方法或会话发起协议中的发布方法将业务发现信 息传递给所述终端， 或与终端之间建立消息会话中继协议会话后， 通过建立 的会话将业务发现信息传递给所述终端。
一种业务发现功能实体， 该实体包括：
确定模块， 用于确定终端是否接入 IP多媒体子系统；
传递模块， 用于当所述确定模块获得的结果为所述终端接入 IP多媒体子 系统时， 通过会话发起协议中的消息方法或会话发起协议中的发布方法将业 务发现信息传递给所述终端， 或与终端之间建立消息会话中继协议会话后， 通过建立的会话将业务发现信息传递给所述终端。 在本发明实施例中， 通过当 SDF获知 UE成功接入 IMS后， 利用会话发 起协议 （ SIP ) 中的消息方法 ( MESSAGE ) 或会话发起协议中的发布方法 ( PUBLISH )将业务发现信息传递给所述终端， 或与终端之间建立消息会话 中继协议 ( MSRP )会话后， 通过建立的会话将业务发现信息传递给所述终端 的方法， 不仅实现了在 IMS中 SDF向 UE传递业务发现信息的过程， 进一步 地， 还使得传递业务发现信息的过程更加灵活、 方便。 附图说明
图 1为背景技术中基于 IMS的 IPTV的业务功能构架的示意图； 图 2为背景技术中业务发现功能实体向用户终端发送业务发现信息的信 令流程示意图；
图 3为本发明实施例一中传递业务发现信息的系统结构示意图； 图 4为本发明实施例二中传递业务发现信息的方法步骤流程示意图； 图 5为本发明实施例三中利用 SIP中的消息方法传递业务发现信息的流 程示意图；
图 6为本发明实施例四中利用 SIP中的发布方法传递业务发现信息的信 令流程示意图；
图 Ί为本发明实施例五中以 UE发起消息会话中继协议会话建立请求， 实现业务发现信息传递的过程的信令流程示意图；
图 8为本发明实施例六中以业务发现功能实体发起消息会话中继协议会 话建立请求， 实现业务发现信息传递的过程的信令流程示意图；
图 9为本发明实施例七中业务发现功能实体的结构示意图。 具体实施方式
为了实现本发明目的，本发明实施例中充分利用 SIP协议中的协议简单、 扩展性能好和灵活性好等优点，提出了 SDF通过 SIP协议中的消息方法（SIP MESSAGE ), 发布方法（SIP PUBLISH )或与 UE之间建立消息会话中继协 议（MSRP )会话， 来向 UE传递业务发现信息的方案， 下面结合说明书附图 对本发明实施例进行详细的描述。
如图 3所示，为本发明实施例一中传递业务发现信息的系统结构示意图， 从图中可以看出该系统包括终端 11和业务发现功能实体 12。
终端 11 包括接入模块 21和接收模块 22, 其中， 接入模块 21用于接入 IP多媒体子系统； 接收模块 22用于接收业务发现信息。
业务发现功能实体 12包括确定模块 31和传递模块 32, 其中， 确定模块 31用于确定终端 11是否接入 IP多媒体子系统；传递模块 32用于当所述确定 模块 31的获得的结果为终端接入 IP多媒体子系统时， 通过 SIP MESSAGE 或 SIP PUBLISH将业务发现信息传递给所述终端， 或与终端之间建立 MSRP 会话后， 通过建立的会话将业务发现信息传递给所述终端 11。
终端 11与业务发现功能实体 12之间的工作过程为： 当确定模块 31获知 接入模块 21成功接入 IMS之后， 指示传递模块 32将业务发现信息传递给接 收模块 22。
当终端 11接收到所述业务发现信息后还可以包括获取模块 23 , 用于根 据所述业务发现信息中的媒体流地址或统一资源标识提供的入口信息获取业 务选择信息。
在本发明实施例中， 业务发现信息为 IPTV业务发现信息。
与上述系统对应的， 本发明实施例二还提供一种实现传递业务发现信息 的方法， 如图 4所示， 该方法包括：
步骤 401： SDF确定 UE接入 IMS网络。
UE完成网络附着后， 发起一个标准的 IMS注册流程后， 成功接入 IMS 网络。
需要让 SDF获知 UE成功接入 IMS , 实现的方法有多种， 包括但不限于： 1、 UE接入 IMS后， 向 SDF发送业务发现信息的请求， 当 SDF接收到 所述请求时， 默认终端已成功接入 IMS; 2、 SDF向状态服务器（Presence Server, PS )订阅 UE的状态信息， 当 UE成功接入 IMS后， PS将成功接入的状态信息发送给 SDF;
3、 当 UE接入 IMS之后， S-CSCF向 SDF发送第三方注册请求， 则确定 终端接入 IP多媒体子系统。
步骤 402: SDF将通过 SIP协议将业务发现信息传递给 UE。
SDF将业务发现信息通过 SIP协议传输给 UE 包括但不限于： SDF通过 SIP MESSAGE传递业务发现信息、 SDF通过 SIP PUBLISH传递业务发现信 息或 SDF通过协商建立消息会话中继协议（MSRP )后传递业务发现信息。 后续将分别这三种情况进行详细描述。
如表 1所示， 为本发明实施例中 IPTV业务发现信息的内容示意图， 从 表中可以看出， 该业务发现信息包括版本号、 状态和业务提供者信息。 其中， 版本号信息描述了 SDF传递给 UE的业务发现信息的版本号， 根据该版本号 信息可以判断业务发现信息是否需要更新。 状态信息描述了 SDF传递的业务 发现信息是包含所有的业务发现信息还是只包含更新的信息。 若状态信息中 描述了 SDF传递的业务发现信息只包含更新的信息， 则当根据所述版本号确 定业务发现信息需要更新时， SDF传递的信息中可以只包含更新的信息。
业务提供者的信息包含域名、 标识入口 （LogoURI )、 版本号和负荷信息 ( Offering )。 其中， 域名可以惟一标识业务提供者， LogoURI可以提供该业 务提供者的 Logo信息， 而版本号信息与前述不同，是描述该域名标识的业务 提供者的业务发现信息的版本。
Offering中包含了负荷标识、版本号、 业务入口地址信息。 负荷标识用于 标识可以进一步获取的业务信息的类型， 例如对于业务选择信息， 包含所有 的信息， 或是只包含 EPG信息和 /或 CoD Catalogue信息等。 版本号描述了负 荷信息的版本号。业务入口地址信息描述了进一步获取业务信息的入口地址， 终端可以根据业务入口地址信息获取业务信息的入口地址， 例如若该入口地 址提供业务选择信息， 则终端可以通过该入口地址获取业务选择信息； 若该 入口地址提供业务密钥信息，则终端可以通过该入口地址获取业务密钥信息。 根据业务信息的不同提供方式， 需要提供不同的业务入口地址类型， 包括但 不限于： 媒体流形式（Stream )或统一资源标识形式（URI )。 在业务信息通 过媒体流方式提供时， 业务发现信息中包含 Stream类型信息， 向 UE提供媒 体流地址 /端口信息， UE根据这些信息进一步获取业务信息， 例如业务选择 信息。 当该媒体流以组播的方式提供时， 这里的地址信息为组播地址， UE可 以进一步加入组播组获取业务信息。 在业务入口信息通过 URI方式提供时， 业务发现信息中包含 URI类型信息， 向 UE提供 URI信息， UE根据 URI信 息进一步获取业务信息。
Figure imgf000009_0001
表 1
为了实现向 UE传送上述内容的业务发现信息， 可以定义一个内容格式 ( Content-Type ) , 该 Content- Type 可以为 application/sd+可扩展标记语言 ( xml ), application/sd+ xml可以通过下述程序实现： <?xml version:" 1.0" encoding=nUTF-8"?>
<xs:schema xmlns=num:xxxx:params:xml:ns:servicediscoveryinfo"
xmlns:xs="http://www. w3.org/2001/XMLSchema"
targetNamespace=num:xxxx:params:xml:ns:servicediscoveryinfo"
elementFormDefault="qualified" attributeFormDefault="unqualifiedn>
<xs:element name="ServiceDiscoveryInfo" type="ServiceDiscoveryInfoType"/>
/^ServiceDiscoverylnfo对应业务发现信息 , 包含一个或者多个 ServiceProviderlnfo*/ <xs:complexType name="ServiceDiscoveryInfoType">
<xs:sequence>
<xs: element name="ServiceProviderInfo" type=" ServiceProviderlnfoType" maxOccurs="unbounded"/>
/^ServiceProviderlnfo 对应业务提供者信息
</xs:sequence>
<xs: attribute name="Version" type="VersionType" use="required"/>
<xs: attribute name="State" use=" optional" default=nfuH">
/*这里 Version为业务发现信息的版本号； State为业务发现信息的状态信息， 表示业务发现信息包含所有的业务发现信息还是只包含部分的业务发现信息 */ <xs:simpleType>
<xs restriction base="xs:stringn>
<xs： enumeration
<xs： enumeration
Figure imgf000010_0001
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="ServiceProviderInfoType">
<xs:sequence>
<xs: element name=" ServiceProvider-Name" type=nMultilingualType" maxOccurs="unbounded"/>
<xs: element name="ServiceProvider-Description" type="MultilingualType" minOccurs=，，0，， maxOccurs="unbounded"/>
<xs: element name=nServiceProvider-Oflfering" type=' fferingType" minOccurs=，，0，， maxOccurs="unbounded"/> /*这组为业务提供者信息包含的元素， 包括业务提供者的名称（Name ), 描述（Description ) 以及提供的业务发现信息 （ServiceProvider-Offering )
</xs:sequence>
<xs: attribute name="DomainName" type=nDomainType" use="required"/>
<xs: attribute name=， ogoURJ" type="xs:anyURI" use=" optional"^
<xs: attribute name="Version" type="VersionType" use="required"/>
/*这组为业务提供者信息的属性， 包括惟一标识业务提供者的 DomainType, 提供 Logo的 LogoURI, 以及业务提供者信息的版本号 （Version ) */ </xs:complexType>
<xs:complexType name="MultilingualTypen>
<xs:simpleContent>
<xs:extension base="xs:stringn>
<xs: attribute
Figure imgf000011_0001
</xs: extension
</xs:simpleContent>
</xs:complexType>
/*上面是一个类型描述， 说明 ServiceProviderlnfo 中 Name, Description是有语言属性的， 可以是多种语言
<xs:complexType name=' fferingType">
<xs: choice maxOccurs="unbounded">
<xs: element name=' ffering-Stream" type="StreamType" maxOccurs="unbounded"/>
<xs: element name='Offering-URI" type="URIType" maxOccurs="unbounded"/>
</xs:choice>
<xs： attributeGroup ref="PayLoad"/>
</xs:complexType>
/*上面是对 ServiceProvider提供业务发现信息方式的定 义， 包含流媒体形式（ Streaming )和 URI形式 */
<xs： complexType name=" StreamType">
<xs: attribute
Figure imgf000011_0002
<xs: attribute name="Address" type=nIPorDomainType" use="required"/> <xs: attribute name="Port" type="xs:unsignedShort，， use="required，，/〉 </xs:complexType>
/*上面对流媒体形式进行具体定义， 需要向用户提供 入口信息的组播 /单播地址， 端口信息 */
<xs:complexType name="U IType">
<xs: attribute name="URI" type=Mxs:anyURI" use="required"/>
</xs:complexType>
/*上面对 URI形式进行具体定义， 需要向用户提供入口信息的 URJ地址 */ <xs： attributeGroup name="PayLoad">
<xs: attribute name="PayLoad-ID" use=" optional" default="All"〉
<xs:simpleType>
<xs:restriction base=,,xs:string">
<xs:enumeration
Figure imgf000012_0001
<xs： enumeration value="EPG"/>
<xs:enumeration value="CoD-Catalogue"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs: attribute name="Version" type=,,VersionType" use="required"/>
</ xs： attributeGroup>
/*上面定义了 ServiceProviderlnfo 的一系列属性， 包括业务提供商 ServiceProviderlnfo 的版本号， 以及负荷类型 （ Payload-ID ), 负荷类型确 定了业务提供商可以提供什么样的信息， 至少包括提供所有的信息， 提供 电子节目导航， CoD-Catalogue*/
<xs:simpleType name="IPorDomainType">
<xs:union memberTypes="IPType DomainType"/>
</xs:simpleType>
<xs:simpleType name="IPTypen>
<xs:restriction base="xs:stringn>
<xs:pattern
value=' (([l-9]?[0-9])|(l[0-9][0-9])|(2[0-4][0-9])|^
0
][0-9])|(25[0-5]))*V> </xs:restriction>
</xs:simpleType>
<xs:simpleType name="DomainType">
<xs:restriction base="xs:stringn>
<xs:pattern value="((.|\n|\r)*)?(\.(.|\n|\r)*)+，，/〉
</xs:restriction>
</xs:simpleType>
<xs:simpleType name=,,IS0639-2">
<xs:restriction base=,,xs:string">
<xs:pattern value="\c\c\c"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="VersionType">
<xs:restriction base=,,xs:integer">
<xs:minlnclusive value="0"/>
<xs:maxlnclusive value="255"/>
</xs:restriction>
</xs:simpleType>
/*上面定义了一些数据类型， 包括域名， IP地址， 版本号， 语言属性等
*/
</xs:schema>
特别的， 当业务发现功能与业务选择功能等其它业务功能合设时， 即当 业务发现功能可以提供业务选择信息等其它业务信息时， 业务发现信息中的 负荷部分可以直接携带业务选择信息等业务信息， 而不是入口地址信息。
下面分别以 SIP MESSAGE, SIP PUBLISH和建立 MSRP连接后传递业 务发现信息为例， 详细描述实施例二。
如图 5所示， 为本发明实施例三中， 利用 SIP MESSAGE传递业务发现 信息的信令流程示意图， 从图中可以看出， 该实施例三包括以下步骤：
步骤 501： UE成功接入 IMS网络。
UE接入 IMS网络的方法包括但不限于： UE发起并完成网络附着后， 再 发起一个 IMS注册流程。 步骤 502: IMS网络向 SDF发送第三方注册请求（ SIP REGISTER )„ 当 UE在 IMS网络注册成功后， IMS中的 S-CSCF从用户签约服务功能 实体（UPSF ) 中获取该 UE的用户签约信息， 当获取的所述用户签约信息满 足设定条件时（如该用户签约信息与预先设定的信息匹配）， IMS中的 S-CSCF 发送 SIP REGISTER。
步骤 503: SDF响应该 SIP REGISTER, 则返回成功响应消息 （ SIP 200 οκ )。
通过步骤 501至步骤 503 , SDF确定 UE已成功接入 IMS„
步骤 504: SDF通过 SIP MESSAGE消息将 IPTV业务发现信息发送给 UE。
所述 IPTV业务发现信息包括但不限于表 1中描述的内容的部分或全部， 该 IPTV业务发现信息可以通过 SIP MESSAGE中的 message body携带。
具体地， SIP MESSAGE消息各部分中携带 IPTV业务发现信息为： Request URI中携带接收所述 IPTV业务发现信息的 UE的 SIP URI或 IP地址等信息； From头域中携带业务发现功能（ SDF ) 的 SIP URI或 IP地址等信息； To头 域为接收所述 IPTV 业务发现信息的 UE 的 SIP URI 或 IP 地址等信息； Content- Type头域携带定义的 application/sd+xml； message body携带具体的 IPTV业务发现信息， 该信息以 application/sd+xml的形式发送。
该 SIP MESSAGE消息体的具体描述可以如下述程序所示：
MESSAGE sip:userl@iptv.com SIP/2.0
From: sip： sdf . iptv . com;tag=49583
To: sip:user l@iptv.com
CSeq: 1 MESSAGE
Content-Type: application/sd+xml
Content-Length: xx
<?xml version:" 1.0" encoding="UTF-8"?>
<ServiceDiscoveryInfo xmlns="urn:xxxx:params:xml:ns:sdinfo"
xmlns:xsi="http://www.w3. org/200 l/XMLSchema-instance" xsi:schemaLocation="urn:xxxx:params:xml:ns:sdinfo\SD.xml"
State="full" Version="001">
/*这里 State="Full"表示包含所有的 IPTV业务发现信息， Version表示业务发现信息的版本号 */
<ServiceProviderInfo LogoU I="http://spl. iptv.com/logo" DomainName="s l .iptv.com"
Version="001">
/*这里通过<861^ 6?«^(161"¾1"0>表示该信息为特定业务提供者 的， 其中 DomainName惟一确定了该业务提供者。 */
<ServiceProvider-Name Language="Eng"> SPl</ServiceProvider-Name> <ServiceProvider-Description Language="Eng">Provides the IPTV
Service</ServiceProvider-Description>
<ServiceProvider-Offering PayLoad-ID="AH" Version:" 001">
/*这里 PayLoad-ID表示 IPTV业务发现信息所提供的入口可以 提供的信息类型， 例如， 当该入口为业务选择信息的入口地 址时， 该信息可以是 EPG, CoD Catalogue等， "All"表示包含 所有的类型。用户终端可以才艮据获取的负荷类型确定可以获 取的信息。 */
<Offering-Stream Port="1702" Address="10.144.75.8"/>
/*这里 Offering-Stream表示入口信息为流媒体地址信息， 用
户终端可以通过该地址以流媒体的形式进一步获取相关 的
业务信息。 */
</ServiceProvider-Offering>
</ S erviceProviderInfo>
<ServiceProviderInfo LogoURI=http://sp2. iptv.com/logo DomainName="sp2. iptv.com"
Version="0">
<ServiceProvider-Name Language="Eng">SP2</ServiceProvider-Name> <ServiceProvider-Description Language="Eng">Provides the
LTV</ServiceProvider-Description>
<ServiceProvider-Offering PayLoad-ID="EPG" Version="012">
<Offering-URI U I="http://sp2.iptv.com//epg/"/> /*这里 Offering-URI表示入口地址为 URI类型， 用户 终端可以通过该 URI进一步获取相关业务信息。
</ServiceProvider-Offering>
</ S erviceProviderInfo>
</ServiceDiscoveryInfo>
UE接收到 SDF发送的 IPTV业务发现信息后，进一步地可以根据该业务 发现信息获取相关业务信息， 例如业务发现信息中包含业务选择信息的入口 地址， 则终端可以根据该入口信息获取业务选择信息。
本发明实施例四是通过 SIP PUBLISH传递业务发现信息的， 该过程如图 6所示， 包括：
步骤 601： SDF确定 UE的状态为成功接入 IMS。
在本实施例中， 该确定过程可以包括：
1、 SDF订阅 UE的状态信息。 在 UE签约 IPTV业务后 , SDF通过标准 的订阅 /通知（ IMS SUBSCRIBE/NOTIFY )机制向 PS订阅 UE状态。 另夕卜， 也可以由 SDF自己管理用户状态。
2、 UE发起并完成网络附着。
3、 UE发起 IMS注册流程。
4、 UE向 PS发布自身的状态信息， 该状态信息可以为 UE上线等信息。 UE可以通过 IMS PUBLISH发布状态信息， 也可以通过网络实体代理自身发 布状态信息。
5、 PS将 UE的状态信息通知给 SDF, 则 SDF可以实时确定 UE的状态， 当状态信息为成功接入时， 确定 UE接入 IMS。
步骤 602: SDF通过 SIP PUBLISH消息向 UE发送 IPTV业务发现消息， 其中， 该消息是通过 message body携带。
在本实施例中， 业务发现信息可以为 SSF的选择信息， 并且相关信息可 以通过自定义的 application/sd+xml形式发送， 所述相关信息包括但不限于： IPTV业务提供者的描述信息、 SSF的入口地址信息。
具体地， SIP PUBLISH消息中各部分携带 IPTV业务发现信息为： Request URI中携带接收所述 IPTV业务发现信息的 UE的 SIP URI或 IP地址等信息； From头域中携带 SDF的 SIP URI或 IP地址等信息； To头域为接收所述 IPTV 业务发现信息的 UE的 SIP URI或 IP地址等信息； Content-Type头域携带定 义的 application/sd+xml; Event头域表明传递的信息为业务发现信息； message body携带具体的 IPTV业务发现信息， 包括但不限于表 1中描述的部分和全 部的内容。
下述程序为 SIP PUBLISH消息体的具体描述：
PUBLISH sip:user l@iptv.com SIP/2.0
From: sip： sdf . iptv . com;tag=49583
To: sip:user l@iptv.com
CSeq: 1 PUBLISH
Event: sd-information
Content-Type: application/sd+xml
Content-Length: xx
<?xml version:" 1.0" encoding="UTF-8"?>
<ServiceDiscoveryInfo xmlns="urn:xxxx:params:xml:ns:sdinfo"
xmlns:xsi="http://www.w3. org/200 l/XMLSchema-instance" xsi:schemaLocation="urn:xxxx:params:xml:ns:sdinfo\SD.xml" State=" l" Version="001">
/*这里 State="Full"表示包含所有的 IPTV业务发现信息， Version表示业务发现信息的版本号 */
<ServiceProviderInfo LogoU I="http://spl. iptv. com/logo"
DomainName="s l .iptv.com" Version="001">
/*通过 <861^ 6?1"0¥1(^¾1~0>表示该信息为特定业务提供者的， 其中 DomainName惟一确定了该业务提供者。 */
<ServiceProvider-Name Language="Eng"> SPl</ServiceProvider-Name>
<ServiceProvider-Description Language="Eng">Provides the IPTV
Service</ServiceProvider-Description>
<ServiceProvider-Offering PayLoad-ID="AH" Version:" 001"> /* PayLoad-ID表示 IPTV业务发现信息的负荷类型， 包括
EPG, CoD Catalogue等， "All"表示负荷包含所有的类型。 */ <Offering-Stream Port="1702" Address- ' 10.144.75.8 "/>
/*这里 Offering-Stream表示入口信息为流媒体组播地址。
</ServiceProvider-Offering>
</ S erviceProviderInfo>
<ServiceProviderInfo LogoU I=http://sp2. iptv.com/logo
DomainName="sp2. iptv.com" Version="0">
<ServiceProvider-Name Language="Eng">SP2</ServiceProvider-Name>
<ServiceProvider-Description Language="Eng">Provides the
LTV</ServiceProvider-Description>
<ServiceProvider-Offering PayLoad-ID="EPG" Version="012">
<Offering-HTTP U I="http://sp2.iptv.com//epg/"/>
/*这里 Offering-URI表示入口地址为 URI类型。 */
</ServiceProvider-Offering>
</ S erviceProviderInfo>
</ServiceDiscoveryInfo>
"sd-information"是新定义的对象 ( Event ) , 也可以使用现有的 Event。 "application/sd+xml"是新定义的 Content-Type, 用于携带 IPTV业务选择 信息。
本发明实施例五和实施例六是通过 MSRP协商建立会话后传递业务发现 信息的， MSRP是由 IETF制定的一个基于文本、 面向连接的传输协议， 可以 用于交换任意的（包括二进制 )多用途互联网邮件扩展（ Multipurpose Internet Mail Extensions, MIME ) 内容， 尤其是用于即时消息。
MSRP通过 SIP和 SDP来协商建立消息会话， 应用 MSRP时， 首先需要 协商源端和目的端之间将要传输的媒体属性，这一协商过程可以由 SIP和 SDP 信令承载并发送， 然后根据协商之后的端口号和媒体属性进行媒体数据的传 送。 MSRP支持的媒体数据类型为 MIME格式的任意数据， 例如文本、 音频、 视频等等。 在本实施例中， UE 和 SDF 之间通过提供 /应答模型 （Offer/Answer Model ), 由 SDP携带 MSRP媒体信息进行协商， 当协商成功时， 建立 MSRP 会话， 然后通过 MSRP协议进行 IPTV业务发现信息的传送。
本发明实施例五是以 UE发起 MSRP会话建立请求， 实现业务发现信息 传递的过程， 具体流程如图 7所示， 包括：
步骤 701： UE通过 IMS向 SDF发送 SIP INVITE请求。
在此步骤之前， UE完成网络附着， 并在 IMS中注册成功。
UE将 SIP INVITE请求发送给 Core IMS , 由 Core IMS将 SIP INVITE请 求转发给 SDF。
UE向 SDF发送 SIP INVITE请求是用于协商建立一个 MSRP会话的，在 该 SIP INVITE请求中的 Request URI携带 SDF的 SIP URI或 IP地址等信息， 这些信息可以通过预先配置或 DHCP等方式获取。
在本实施例中使用 PSI 标识 SDF, 因此可以通过 PSI路由方式将 SIP INVITE请求发送到 SDF; 另外， 还可以釆用初始过滤规则 （iFC )触发方式 实现路由。
UE通过 SDP将自身的 MSRP媒体信息发送给 SDF,要求与 SDF进行媒 体协商， 该 UE的 MSRP媒体信息包括：
SDP连接信息行（Connection Line, c ), 其中携带了 UE的地址信息， 例 如： c=IN IP4 userl .iptv.com。
SDP媒体行（Media Line, m ) ， 其中携带了媒体的信息， 如传输信息。 媒体类型为 message, 端口为 UE接收业务发现信息的端口号， 如果是 MSRP承 载在传输控制协议上（MSRP over TCP ) , 则协议为 TCP/MSRP, 格式列表为 例如： m=message 7777 TCP/MSRP *。
SDP属性行 ( Attribute Line, a )必须包含路径信息（ path )和 content type, 其中， path指明 message的传输路径， 包含 UE的地址信息； content type指 明 message传输的类型， 即定义的 application/sd+xml。 1*列 ^口： a= content types： application/ sd+xml；
a=path:msrp：〃 userl .iptv.com:7777/qwertl234asdf;tcp。
上述 UE的 MSRP媒体信息是利用 SIP INVITE请求发送的。
步骤 702: SDF将自身的 MSRP媒体信息发送 UE。
SDF接收到 UE发送的 SIP INVITE请求后， 获取 SDP中携带的 MSRP 媒体信息， 并在 SDP中携带自身的 MSRP媒体信息， 通过 SIP 200 OK消息 将这些信息发送给 UE。
SDF自身的 MSRP媒体信息包括：
SDP连接信息行， 携带了 SDF地址信息， 例如： c=IN IP4 sdf.iptv.com;
SDP媒体行， 携带媒体信息， 与 UE发送的 SDP媒体行信息不同之处在于 端口为 SDF的端口号， 例 ¾口： m=message 8888 TCP/MSRP
SDP属性行， 包含 path和 content type,其中， path指明 message的传输路径， 包含 SDF的地址信息； content type指明 message传输的类型， 即定义的 application/sd+xml , 例如：
a= content types: application/sd+xml;
a=path:msrp://sdf.iptv.com:8888/ asdfg4321qwer;tcp。
步骤 703: UE与 SDF完成 MSRP协商， 建立 MSRP会话和传输通道。 步骤 704: SDF通过建立的 MSRP会话和传输通道将 IPTV业务发现信 息传递给 UE。
在本实施例中 , SDF通过 MSRP SEND消息向 UE发送 IPTV业务发现信 息， IPTV 业务发现信息为可用的 IPTV 业务信息， 并且该信息通过定义的 application/sd+xml形式发送， 这些信息可以包括但不限于表 1 中描述的部分 或全部内容。
SEND消息的具体描述可以如下程序所示：
MSRP qwertl23 SEND
To-Path: msrp://userl .iptv.com:7777/ qwertl234asdf;tcp From-Path: msrp://sdf.iptv.com:8888/ asdfg4321 qwer;tcp
Message-ID: asdfgl23
Byte-Range: 1-21/21
Content-Type: application/sd+xml
<?xml version:" 1.0" encoding=nUTF-8"?>
<ServiceDiscoveryInfo xmlns=nurn:xxxx:params:xml:ns:sdinfo"
xmlns:xsi="http://www.w3. org/200 l/XMLSchema-instance" xsi:schemaLocation=num:xxxx:params:xml:ns:sdinfo\SD.xmr' State=" l" Version=' 01">
<ServiceProviderInfo LogoU I="http://spl. iptv.com/logo"
DomainName="spl .iptv.com" Version=，O01">
<ServiceProvider-Name Language="Eng"> SP 1 </ServiceProvider-Name>
<ServiceProvider-Description Language="Eng">Provides the IPTV
Service</ServiceProvider-Description>
<ServiceProvider-Offering PayLoad-ID=nAH" Version=n001">
<Offering-Stream Port="1702" Address="10.144.75.8 >
</ServiceProvider-Offering>
</ S erviceProviderInfo>
<ServiceProviderInfo LogoU I=http://sp2. iptv.com/logo
DomainName="sp2. iptv.com" Version="0">
<ServiceProvider-Name Language="Eng">SP2</ServiceProvider-Name>
<ServiceProvider-Description Language="Eng">Provides the
LTV</ServiceProvider-Description>
<ServiceProvider-Offering PayLoad-ID="EPG" Version=' 12">
<Offering-HTTP U I="http://sp2.iptv.com//epg/"/>
</ServiceProvider-Offering>
</ S erviceProviderInfo>
</ServiceDiscoveryInfo>
qwertl23$
步骤 705: UE接收到所述 IPTV业务发现信息后， 向 SDF返回确认消息
( MSRP 200 OK )。
UE可以利用所述 IPTV业务发现信息中入口信息， 例如 stream或 URI 等， 进一步获取业务选择信息。 如图 8所示，为本发明实施例六中由 SDF发起 MSRP会话建立请求来传 递业务发现信息的过程示意图， 从图中可以看出该过程包括：
步骤 801： 当 SDF确定 UE成功接入 IMS后， 向 UE发送 SIP INVITE请 求。
此步骤包括：
1、 UE发起并完成网络附着。
2、 UE发起 IMS注册流程， 在 IMS成功注册。
3、 S-CSCF 获取注册流程中的 public user identity, 确定该 public user identity匹配的 iFC。
4、 S-CSCF 向 SDF发起第三方注册请求（SIP REGISTER ), 在该 SIP REGISTER的 "To: " 头域中包含上述 public user identity。
5、 SDF响应该 SIP REGISTER消息， 向 S-CSCF返回 SIP 200 OK消息。 6、 SDF将 SIP INVITE请求通过 Core IMS转发给 UE, 用于与 UE之间 协商建立一个 MSRP会话， 进而来传输 IPTV业务发现信息。
在本实施例中用 PSI来标识 SDF,因此该传输 SIP INVITE请求的流程可 以为一个 IMS AS始呼流程， 即 PSI到用户的路由过程。
SDF向 UE发送的 SIP INVITE请求中的 Request URI携带 UE的 SIP URI 或 IP地址等信息， SDF可以通过第三方注册或预先配置等方式获取。
SDF获取 SDP中的 MSRP媒体信息， 并在 SDP中携带自身的 MSRP媒 体信息， 通过 SIP INVITE请求将这些信息发送给 UE, 例如， SDF 自身的 MSRP媒体信息包括：
c=IN IP4 sdf.iptv.com；
m=message 7777 TCP/MSRP *;
a= content types: application/sd+xml;
a=path:msrp：〃 sdf.iptv.com:7777/qwertl234asdf;tcp。
步骤 802: UE将自身的 MSRP媒体信息发送给 SDF。
UE将包含自身的 MSRP媒体信息的 SIP 200 OK信息发送给 Core IMS, Core IMS将所述 SIP 200 OK信息转发给 SDF, 例如， UE的 MSRP媒体信息 包括：
c=IN IP4 userl.iptv.com；
m=message 8888 TCP/MSRP *;
a=content types: application/ sd+xml；
a=path:msrp://userl.iptv.com:8888/ asdfg4321qwer;tcp。
步骤 803: UE与 SDF之间完成 MSRP协商， 建立 MSRP会话和传输通 道。
步骤 804: SDF通过建立的 MSRP会话和传输通道将 IPTV业务发现信 息传递给 UE。
在本实施例中， SDF通过 MSRP SEND消息向 UE发送 IPTV业务发现信 息， 该 IPTV业务发现信息是通过 message body携带。
IPTV 业务发现信息为可用的 IPTV 业务信息， 并且该信息通过定义的 application/sd+xml形式发送， 这些信息可以包括但不限于表 1 中描述的部分 或全部内容。
SEND消息的具体描述可以如下程序所示：
MSRP qwertl23 SEND
To-Path: msrp://userl.iptv.com:8888/ asdfg4321 qwer;tcp
From-Path: msrp://sdf.iptv.com:7777/ qwertl234asdf;tcp
Message-ID: asdfgl23
Byte-Range: 1-21/21
Content-Type: application/sd+xml
<?xml version:" 1.0" encoding=nUTF-8"?>
<ServiceDiscoveryInfo xmlns=nurn:xxxx:params:xml:ns:sdinfo"
xmlns:xsi="http://www.w3. org/200 l/XMLSchema-instance" xsi:schemaLocation=num:xxxx:params:xml:ns:sdinfo\SD.xmr' State=" l" Version=' 01">
<ServiceProviderInfo LogoU I="http://spl. iptv.com/logo"
DomainName="spl .iptv.com" Version=，O01">
<ServiceProvider-Name Language="Eng"> SP 1 </ServiceProvider-Name> <ServiceProvider-Description Language="Eng">Provides the IPTV
Service</ServiceProvider-Description>
<ServiceProvider-Offering PayLoad-ID="AH" Version:" 001">
<Offering-Stream Port="1702" Address- ' 10.144.75.8 "/>
</ServiceProvider-Offering>
</ S erviceProviderInfo>
<ServiceProviderInfo LogoU I=http://sp2. iptv.com/logo
DomainName="sp2. iptv.com" Version="0">
<ServiceProvider-Name Language="Eng">SP2</ServiceProvider-Name>
<ServiceProvider-Description Language="Eng">Provides the
LTV</ServiceProvider-Description>
<ServiceProvider-Offering PayLoad-ID="EPG" Version="012">
<Offering-HTTP U I="http://sp2.iptv.com//epg/"/>
</ServiceProvider-Offering>
</ S erviceProviderInfo>
</ServiceDiscoveryInfo>
qwertl23$
此过程与实施例五中的 To-Path和 From-Path路径不同。
步骤 805: UE接收到所述 IPTV业务发现信息后 ,向 SDF返回 MSRP 200 OK：。
UE可以利用所述 IPTV业务发现信息中的 stream或 URI等信息获取业务入 口信息， 进一步获取业务选择信息。 基于不同的业务发现信息， UE可以通过 不同的方式获取业务选择信息：
1、 当入口信息为 stream时 , UE可以通过获取的地址信息获取 IPTV业务 选择信息， 例如当业务选择信息以组播的形式下发时， 用户终端根据获取的 组播地址， 加入组播组， 获取 IPTV业务选择信息， 例如 IGMP Join。
2、 当入口信息为 URI时， 包括以下情况：
( 1 ) 、 当入口信息为统一资源定位符（URL )等时， UE可以通过 HTTP 等协议获取 IPTV业务选择信息。
( 2 ) 、 当入口信息为 SIP URI时， UE可以通过 MSRP协议获取 IPTV 业务选择信息， MSRP会话协商与获取 IPTV业务发现信息的 MSRP会话协 商类似。
通过上述实施例的描述， 给出了 SDF向 UE传递业务发现信息的具体过 程， SDF可以多次向 UE传递业务发现信息。 SDF传递的业务发现信息可以 不同， 例如： SDF将当前待传递的业务发现信息全部传递给 UE, 或者 SDF 比较当前待传递的业务发现信息与前一次传递的业务发现信息之间的变化， 然后 ,将发生变化的信息传递给 UE。后一种情况可以适用于数据升级等过程。
具体地， 比较两次传递的业务发现信息可以是比较其中的版本标识， 当 两次业务发现信息中的版本标识发生变化时， 可以认为此时需要升级， 则将 当前待传递的业务发现信息的版本标识对应的信息传递给 UE。
在本实施例中并不限定比较依据， 也可以对业务发现信息中的其他内容 进行比较。
不论是全部重新发送， 还是部分更新， 都可以利用上述实施例中描述的 方式来实现。特别地，在实施例五和实施例六的情况中 , SDF向 UE传递 IPTV 业务发现信息后， SDF和 UE之间的 MSRP会话连接可以保留也可以释放。 若仍然被保留， 则当 IPTV业务发现信息需要更新时， SDF可以利用 MSRP SEND消息向 UE传递更新消息；若会话连接已经被释放，则可以按照实施例 五或实施例六的方式重新建立 MSRP会话连接。
SDF向 UE传递 IPTV业务发现信息之前可以为 UE选择合适的业务发现 信息， 例如选择合适的 SSF, 根据用户的签约信息实现定制的业务发现信息 等。 SDF可以根据 UE的位置信息、 能力和签约信息等来选择合适的 SSF, 例如：
1、 根据 UE的位置信息选择 Service Provider信息。
例如， 当 UE在漫游的状态下， SDF要先获得 UE的位置信息， 将 UE所 在地的 SSF作为合适的 SSF, 即为 UE选择所在位置的 IPTV业务发现信息， 因此， UE接收到的 IPTV业务发现信息中包含当前所在地 IPTV业务提供者 的信息<8611 6^(^(161"11 10>。
SDF 可以通过多种方式获取用户终端位置信息， 例如从位置服务器 ( Location Server )获取。
2、 根据 UE的签约信息选择 Service Provider信息。
用户签约数据可以包括：
( 1 )、个性化 /客户定制业务发现签约信息， 即将个性化 /客户定制作为一 个附加业务提供， 该信息标识用户是否签约个性化 /客户定制业务发现信息；
( 2 )、 语言信息， 即用户签约的语言信息， 可以根据用户的语言信息决 定下发什么样的业务发现信息；
( 3 )、 Service Provider签约信息， IPTV业务可能由多个 SP提供， 用户 可能签约了其中一个或者多个；
( 4 )、 自定义业务发现信息， 例如： 是提供所有 SP的发现信息， 还是只 提供部分 SP的发现信息； 是针对 SP提供所有的业务发现信息， 还是只提供 每个 SP的部分信息， 如入口地址等， 而不需要 SP的描述信息等；
( 5 )、 业务发现信息下发方式， 描述了下发业务发现信息的条件， 例如 定时下发还是有更新数据时下发等；
( 6 )、 收视习惯， 根据用户的收视习惯安排为用户提供的业务发现信息， 例如常用的 SP信息通过醒目的方式提供等。
这些信息可能是动态提供的， 可以由相关的功能实体提供。
例如： 当用户只签约了 CoD业务时， SDF向终端传递的 IPTV业务发现 信息中只包含属性为 "CoD Catalogue" 的<861^。6?1"(^(161"11^0>, 或者只提供 <ServiceProviderInfo>中属性为 "CoD Catalogue" 的业务信息。 SDF可以通过 多种方式获取用户签约信息， 例如 SDF自己保存管理用户签约信息， SDF从 网络实体 UPSF获取用户签约信息， 或者 SDF从其它保存用户签约信息的网 络实体获取用户签约信息。
3、 根据 UE的终端能力选择合适的 Service Provider信息。 终端能力可以包括： 用户终端设备类型 （如： 型号、 版本号 （标识用户 终端客户端软件版本））和用户终端设备能力（屏幕大小、 分辨率、 编解码能 力和支持协议）等。
根据用户终端能力可以为用户提供个性化的业务发现信息。 例如， 用户 的终端只支持标清格式， 则 SDF可以过滤掉只提供高清格式节目的 Service Provider的信息。
SDF可以通过多种方式获取终端能力， SDF从终端获取终端能力， 例如 用户终端在注册时携带终端能力到 SDF; 或者网络中有功能实体获取、 管理 用户终端能力， SDF从该功能实体获取相应的用户终端能力。
在本发明实施例中， SDF对 SSF进行选择来确定要传递的业务发现信息， 实际上， SDF也可以根据终端的请求提供其他功能实体的信息， 如安全保护 功能实体信息。
基于上述对本发明实施例系统和方法实施例的描述， 本发明实施例七为 一种 SDF, 如图 9所示， 其包括： 确定模块 41和传递模块 42, 其中， 确定 模块 41用于确定终端是否接入 IP多媒体子系统； 传递模块 42用于当所述确 定模块获得的结果为所述终端接入 IP多媒体子系统时， 通过 SIP MESSAGE 或 SIP PUBLISH将业务发现信息传递给所述终端， 或与终端之间建立 MSRP 会话后， 通过建立的会话将业务发现信息传递给所述终端。
所述传递模块 42包括比较单元 51和执行单元 52, 其中， 比较单元 51 用于比较待传递的业务发现信息与前一次传递的业务发现信息； 执行单元 52 用于将所述比较单元 51确定的发生变化的信息传递给所述终端。
若以版本标识为比较依据，则比较单元 51用于比较待传递的业务发现信 息与前一次传递的业务发现信息的版本标识；执行单元 52用于当版本标识发 生变化时，将待传递的业务发现信息的版本标识对应的信息传递给所述终端。
若传递模块 42与终端之间建立 MSRP会话，则包括建立单元和操作单元， 其中， 建立单元用于向所述终端发起 MSRP会话建立请求， 或接收所述终端 发起的 MSRP 会话建立请求； 操作单元用于根据所述会话建立请求建立 MSRP会话， 并通过建立的会话将业务发现信息传递给所述终端。
在本发明实施例中， SDF 通过 SIP MESSAGE, SIP PUBLISH, MSRP SEND等方法传送业务发现信息， 也可以使用其它的消息传递业务发现信息， 例如 SIP信息方法（INFO ), SIP订阅 /通知（SUBSCRIBE/NOTIFY )等， 这 里不再详述。
通过本发明实施例提供的系统和方法， 使得 SDF向 UE传递 IPTV业务 发现信息的流程更加灵活、 简便， 并且给出了多种信息更新方式， 简化了用 户操作； SDF可以个性化选择 SSF, 使传递的 IPTV业务发现信息更加可靠， 让用户体 3全较好。 发明的精神和范围。 这样， 倘若本发明的这些修改和变型属于本发明权利要 求及其等同技术的范围之内， 则本发明也意图包含这些改动和变型在内。

Claims

权 利 要求
1、 一种传递业务发现信息的方法， 其特征在于， 该方法包括： 业务发现功能实体确定终端接入 IP多媒体子系统；
所述业务发现功能实体通过会话发起协议中的消息方法 SIP MESSAGE 或会话发起协议中的发布方法 SIP PUBLISH将业务发现信息传递给所述终 端， 或与终端之间建立消息会话中继协议 MSRP会话后， 通过建立的会话将 业务发现信息传递给所述终端。
2、 如权利要求 1所述的方法， 其特征在于， 所述业务发现功能实体确定 终端接入 IP多媒体子系统， 包括：
当所述业务发现功能实体接收到所述终端发送的业务发现信息的请求 时， 确定终端接入 IP多媒体子系统； 或
所述业务发现功能实体订阅所述终端的状态信息， 当所述状态信息为成 功接入时， 确定终端接入 IP多媒体子系统； 或
当所述业务发现功能实体接收到第三方注册请求时， 确定终端接入 IP多 媒体子系统。
3、 如权利要求 1或 2所述的方法， 其特征在于， 所述 SIP MESSAGE或 SIP PUBLISH中：
消息体 message body携带所述业务发现信息；
Request-URI头域中携带接收所述终端的 SIP URI或 IP地址；
来自 From 头域中携带所述业务发现功能实体的会话发起协议统一资源 定位标识 SIP URI或 IP地址；
到达 To头域中携带所述终端的 SIP URI或 IP地址；
Content-Type头域携带业务发现信息消息体类型。
4、 如权利要求 1或 2所述的方法， 其特征在于， 所述业务发现功能实体 与所述终端之间建立 MSRP的会话之前， 包括： 所述业务发现功能实体发起 MSRP 会话建立请求， 或所述终端发起 MSRP会话建立请求。
5、 如权利要求 1、 2或 4所述的方法， 其特征在于， 所述业务发现功能 实体在建立的会话中利用消息会话中继协议发送消息 MSRP SEND将业务发 现信息传递给所述终端。
6、 如权利要求 1至 5中任一所述的方法， 其特征在于， 所述业务发现功 能实体将待传递的业务发现信息全部传递给所述终端， 或
比较待传递的业务发现信息与前一次传递的业务发现信息， 将发生变化 的信息传递给所述终端。
7、 如权利要求 6中所述的方法， 其特征在于， 比较待传递的业务发现信 息与前一次传递的业务发现信息中的版本标识， 若该版本标识发生变化， 则 将待传递的业务发现信息的版本标识对应的信息传递给所述终端。
8、 如权利要求 1至 6中任一所述的方法， 其特征在于， 传递的所述业务 发现信息是根据终端的位置信息、能力和签约信息中的一个或多个来确定的。
9、 一种传递业务发现信息的系统， 其特征在于， 该系统包括终端和业务 发现功能实体， 其中， 所述终端包括：
接入模块， 用于接入 IP多媒体子系统；
接收模块， 用于接收业务发现信息；
所述业务发现功能实体包括：
确定模块， 用于确定所述终端是否接入 IP多媒体子系统；
传递模块， 用于当所述确定模块获得的结果为终端接入 IP多媒体子系统 时 , 通过 SIP MESSAGE或 SIP PUBLISH将业务发现信息传递给所述终端 , 或与终端之间建立 MSRP会话后， 通过建立的会话将业务发现信息传递给所 述终端。
10、 一种业务发现功能实体， 其特征在于， 该实体包括：
确定模块， 用于确定终端是否接入 IP多媒体子系统； 传递模块， 用于当所述确定模块获得的结果为所述终端接入 IP多媒体子 系统时 , 通过 SIP MESSAGE或 SIP PUBLISH将业务发现信息传递给所述终 端， 或与终端之间建立 MSRP会话后， 通过建立的会话将业务发现信息传递 给所述终端。
11、 如权利要求 10所述的业务发现功能实体， 其特征在于， 若所述传递 模块与终端之间建立 MSRP会话， 则包括：
建立单元， 用于向所述终端发起 MSRP会话建立请求， 或接收所述终端 发起的 MSRP会话建立请求；
操作单元， 用于根据所述会话建立请求建立 MSRP会话， 并通过建立的 会话将业务发现信息传递给所述终端。
12、 如权利要求 10或 11所述的业务发现功能实体， 其特征在于， 所述 传递模块包括：
比较单元， 用于比较待传递的业务发现信息与前一次传递的业务发现信 息；
执行单元，用于将所述比较单元确定的发生变化的信息传递给所述终端。
13、 如权利要求 12所述的业务发现功能实体， 其特征在于，
所述比较单元， 用于比较待传递的业务发现信息与前一次传递的业务发 现信息的版本标识；
所述执行单元， 用于当版本标识发生变化时， 将待传递的业务发现信息 的版本标识对应的信息传递给所述终端。
PCT/CN2008/071909 2007-08-17 2008-08-07 Procédé et système pour transférer un message de découverte d'opération et entité fonctionnelle pour une découverte d'opération WO2009024053A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200710146766.0 2007-08-17
CN200710146766.0A CN101369904B (zh) 2007-08-17 2007-08-17 传递业务发现信息的方法、系统及业务发现功能实体

Publications (1)

Publication Number Publication Date
WO2009024053A1 true WO2009024053A1 (fr) 2009-02-26

Family

ID=40377842

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/071909 WO2009024053A1 (fr) 2007-08-17 2008-08-07 Procédé et système pour transférer un message de découverte d'opération et entité fonctionnelle pour une découverte d'opération

Country Status (2)

Country Link
CN (1) CN101369904B (zh)
WO (1) WO2009024053A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101924744A (zh) * 2009-06-10 2010-12-22 中兴通讯股份有限公司 一种融合ip消息消息会话中继协议msrp参数协商的方法
CN110351224A (zh) * 2018-04-03 2019-10-18 成都鼎桥通信技术有限公司 一种sip状态服务的发布方法和装置
CN116627775B (zh) * 2023-07-24 2023-09-29 北京大学 有状态的服务器无感知函数的写优化方法和装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1863330A (zh) * 2005-11-08 2006-11-15 华为技术有限公司 一种实现网络电视消息业务的方法及系统
CN1917457A (zh) * 2005-08-16 2007-02-21 华为技术有限公司 一种接入ip多媒体子系统的方法
CN1998182A (zh) * 2003-02-10 2007-07-11 诺基亚公司 具有ip多媒体子系统(ims)实体的移动网络和用于提供操作的简化和不同ims实体间的兼容的解决方案

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1998182A (zh) * 2003-02-10 2007-07-11 诺基亚公司 具有ip多媒体子系统(ims)实体的移动网络和用于提供操作的简化和不同ims实体间的兼容的解决方案
CN1917457A (zh) * 2005-08-16 2007-02-21 华为技术有限公司 一种接入ip多媒体子系统的方法
CN1863330A (zh) * 2005-11-08 2006-11-15 华为技术有限公司 一种实现网络电视消息业务的方法及系统

Also Published As

Publication number Publication date
CN101369904B (zh) 2011-02-09
CN101369904A (zh) 2009-02-18

Similar Documents

Publication Publication Date Title
JP4927879B2 (ja) Ｉｐｔｖのための、ｉｍｓ対応のコントロールチャネル
EP1988666B1 (en) A streaming media network system, a realization method and a enable entity of streaming media service
CN101573943B (zh) 媒体频道管理
US8326942B2 (en) IP unicast streaming service delivery
KR101433225B1 (ko) Ｉｍｓ 아키텍쳐 네트워크에서 ｉｐ 텔레비젼 서비스에 액세스하기 위한 시스템
CA2761007C (en) Session push transfer
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
US20090147779A1 (en) Methods, iptv (internet protocol television) terminal, and iptv control server for iptv bandwidth management
CN101674323A (zh) 业务推送协商方法及装置、推送业务系统
WO2008049314A1 (fr) Procédé et système pour implémenter un service de multidiffusion ou un service de diffusion générale sur la base d&#39;un réseau de nouvelle génération
WO2009024092A1 (fr) Procédé et système permettant la commande d&#39;autorisation de ressource de service
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
WO2008098500A1 (fr) Procédé et appareil pour découvrir un service de flux de données multimédia et appareil pour découvrir un service
WO2008148326A1 (fr) Procédé, système, agent d&#39;activité et terminal pour réaliser une activité de convergence
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
WO2008154849A1 (fr) Procédé et entité de fonction pour récupérer les informations de sélection du service iptv
WO2009049518A1 (fr) Procédé, système et entité d&#39;établissement de session de système de télévision par internet ip
WO2010012233A1 (zh) 一种交互信息的传送方法、系统和装置
CN101287155B (zh) 一种发现流媒体业务的方法和系统
WO2007131433A1 (fr) Procédé et système d&#39;acheminement d&#39;un message relatif à une demande d&#39;abonnement
Janikowski et al. On extending open source IMS platform for integrated IPTV and VoIP services over IPv6
WO2009056043A1 (fr) Procédé, système et équipement pour obtenir des signets d&#39;enregistrement dans un système de télévision sur ip
EP2061203A1 (en) Method for establishing an IMS-session
WO2008052484A1 (fr) Procédé, système et appareil de commande service tv ip

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: 08783902

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: 08783902

Country of ref document: EP

Kind code of ref document: A1