WO2006109202A1 - Procede et entites permettant d'executer une session de distribution dans un systeme de communication - Google Patents

Procede et entites permettant d'executer une session de distribution dans un systeme de communication Download PDF

Info

Publication number
WO2006109202A1
WO2006109202A1 PCT/IB2006/050849 IB2006050849W WO2006109202A1 WO 2006109202 A1 WO2006109202 A1 WO 2006109202A1 IB 2006050849 W IB2006050849 W IB 2006050849W WO 2006109202 A1 WO2006109202 A1 WO 2006109202A1
Authority
WO
WIPO (PCT)
Prior art keywords
push
session
entity
messaging session
push operation
Prior art date
Application number
PCT/IB2006/050849
Other languages
English (en)
Inventor
Thinh Nguyenphu
Miguel-Angel Garcia-Martin
Original Assignee
Nokia Corporation
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
Priority claimed from US11/155,727 external-priority patent/US20060230154A1/en
Application filed by Nokia Corporation filed Critical Nokia Corporation
Publication of WO2006109202A1 publication Critical patent/WO2006109202A1/fr

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/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • 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 communication systems. More particularly, the invention relates to a method and entities for performing a push session in a communication system.
  • a communication system can be seen as a facility that enables communication sessions between two or more entities such as one or more communication devices and/or other nodes associated with the communication system.
  • a communication system typically operates in accordance with a given standard or specification setting out what the various entities associated with the communication system are permitted to do and how that should be achieved.
  • a standard or specification may define a specific set of rules, such as communication protocols and/or parameters, on which connections between the entities can be based.
  • Wireless communication systems include various cellular or otherwise mobile communication systems using radio frequencies for sending voice or (non-voice) data between stations, for example between a communication device and a transceiver network element.
  • wireless communication systems may comprise public land mobile network (PLMN) , such as global system for mobile communication (GSM) , the general packet radio service (GPRS) and the universal mobile telecommunications system (UMTS) .
  • PLMN public land mobile network
  • GSM global system for mobile communication
  • GPRS general packet radio service
  • UMTS universal mobile telecommunications system
  • a single communication system may interface with one or more other communication systems, such as with other wireless systems, such as a wireless Internet Protocol (IP) network, and/or fixed line communication systems .
  • IP Internet Protocol
  • Subscribers such as the users or end-users, to a communication system may be offered and provided numerous services, such as calls, data communication or multimedia services or simply an access to a network, such as the Internet .
  • Servers may be used in provision of the services and may be operated by an operator of a network or by an external service provider.
  • a wireless application protocol WAP
  • WAP wireless application protocol
  • Further examples of services may comprise, but are not limited to, short message service (SMS) , multimedia messaging service (MMS) , electronic mail (email) , and so on.
  • SMS short message service
  • MMS multimedia messaging service
  • email electronic mail
  • a client of a communication device may request for a service or information from a server, which then responds in transmitting the requested service or information to the client. This may be referred to as a pull operation.
  • An example of a pull operation may comprise a client allowing a user of a communication device to browse the Internet using a WAP or hypertext transfer protocol (HTTP) browser.
  • HTTP hypertext transfer protocol
  • a server may transmit information or content without an explicit request from the client. This may be referred to as a push operation. Examples of push operation are discussed more in detail in the following.
  • a network operator or another party may (remotely) configure a communication device or provide the communication device with content or other information relating to a service.
  • information may comprise, but are not limited to, information relating to device management (DM) .
  • Further non-limiting examples of information may include news, stock quotes, weather, traffic reports and notification of events, such as email or MMS message arrival.
  • advertisements represent an example of such information desired to be and/or being pushed from a server to a client.
  • the information may be transmitted to the communication device over the air (OTA) interface.
  • OTA air
  • the WAP Forum has defined a push OTA protocol for delivering content over the air from a push server to a communication device, such as a WAP enabled communication device.
  • WAP Push Architectural Overview Version 03-JuI- 2001, Wireless Application Protocol, WAP-250- PushArchOverview-20010703-a, outlines the WAP push specifications, which together specify a service to push content to mobile devices via the WAP architecture.
  • a push initiator may transmit (in a push request) push content and delivery - A - instructions to a push proxy gateway (PPG) , which may then deliver the push content to a client in the communication device according to the delivery instructions .
  • a push initiator and a push proxy gateway may be separate entities or co-located in a single entity.
  • a push initiator may be an application desiring to push certain content or represent a co-located entity acting in response to a request to push content on behalf of such an application.
  • a push request from a push initiator PI can be delivered directly or via one or more intermediary network nodes to the push proxy gateway PPG.
  • the push OTA is an application layer protocol that can be run on top of a wireless session protocol (WSP) for connectionless or connection-oriented push or on top of the HTTP protocol for connection-oriented push.
  • the push OTA protocol may thus be referred to as OTA-WSP and OTA- HTTP, respectively.
  • the push proxy gateway PPG may send a request, such as a session initiation request (SIR) , to a communication device to initiate connectivity.
  • SIR session initiation request
  • the request may be sent by connectionless push using the OTA-WSP, such as by means of an SMS.
  • the communication device may then activate a bearer for a session as requested in the request and establish a session towards the PPG.
  • the session may be a WSP or HTTP session or a transmission control protocol (TCP) connection. Details of Push OTA can be found in "Push OTA Protocol Specification", WAP ForumTM, WAP-235-PushOTA, to be retrieved via the OMA web site.
  • a session invitation including a description of a push protocol over a transport protocol for establishing a push session is received; a transport bearer in accordance with said transport protocol is set up; and the transport bearer is used for the push session in accordance with said push protocol .
  • SIP Session Initiation Protocol
  • SIP Session Initiation Protocol
  • MMS Notification MMS Notification
  • Device Management messages XML encoded messages that can be transported either with HTTP or WSP.
  • SIP messages e.g., MESSAGE, NOTIFY, etc.
  • 3GPP2 MMS MMI SIP specification (3GPP2 X.S0016-312 Version 1.0 MMS MMl Stage 3 Using SIP) to be retrieved via www.3GPP2.org web site.
  • Push services in general are distinguishable, for example, according to their type of push operation, as mentioned earlier above. These types of operations are sometime considered as “connectionless” and “connection- oriented".
  • a "connectionless” type of Push service is a "low value” application, such as advertising.
  • the push application wishes to communicate content to a user of a device, and does not require a receipt confirmation of delivery.
  • a "connection-oriented” type of Push service is a "high value” application, such as a stock ticker.
  • the application wishes to push content to a user.
  • the application will use a push proxy, to initiate the communication of the content to the user's device.
  • the push proxy initiating the pushing of the content is also referred to as push initiator PI.
  • the content being communicated necessitates that the push proxy and mobile device may have to establish a common communication context such that confirmation of successful transport of the content is confirmed and subsequently notified back to the originator of the message, the application.
  • the OMA PUSH Service requires an operation, according to which the push service (the application pushing the content) may select to use a push operation with or without a receipt confirmation of delivery.
  • the OMA SIP PUSH technology is defining mechanisms to reuse the reachability functionality offered by SIP, to enable OMA PUSH operations to support push operations with and without confirmation of delivery, to be able to support a large amount of data being pushed from the proxy PPG to client device, to enable to push a variety of media types to the client and to detect client capability and preferences .
  • Pushing of content to a terminal device according to the terminal's capabilities insofar involves a certain registration of the terminal at a push proxy gateway PPG.
  • the term "registration” refers to a procedure where the Push Proxy Gateway (PPG) becomes aware of the device's current capabilities and preferences. The information is conveyed using headers, and may be stored in the PPG to avoid that the information is communicated in future transactions. During this registration procedure, the client and the PPG are also identified and optionally authenticated. The registration procedure is always initiated by the PPG.
  • this object is for example achieved by a method for performing a push operation in a communication system, the method comprising the steps of receiving, at a gateway entity of the communication system, a request to perform a push operation towards a push destination entity, and setting up a connecting session invoking a messaging session for delivering content to be pushed in the push operation towards the push destination entity.
  • this object is for example achieved by a method for performing a push operation in a communication system, the method comprising the steps of receiving, at a gateway entity of the communication system, a request to perform a push operation towards a push destination entity, and setting up a messaging session for delivering content to be pushed in the push operation towards the push destination entity.
  • said method further comprises a step of delivering said content to said push destination entity using said messaging session;
  • said messaging session is a Message Session Relay Protocol, MSRP, session and the connecting session is a Session Initiation Protocol, SIP, session;
  • said content to be pushed is encapsulated in at least one MSRP request;
  • said delivering step comprises a step of configuring said messaging session by setting at least one messaging session parameter to report success of the push operation;
  • the method further comprises a step of reporting, from the push destination entity towards the gateway entity, success of the push operation in a report message of the messaging session;
  • the method further comprises a step of converting, at the gateway entity, the report message of the messaging session into a push result message for further transmission responsive to the request received in the receiving step;
  • said receiving step further comprises a step of analyzing the received request to perform a push operation, wherein said analyzing comprises at least whether the request to perform a push operation requests a connection oriented push operation for which a report of success is required, and said delivering step is configured responsive to said analyzing.
  • this object is for example achieved by an arrangement for performing a push operation in a communication system, the arrangement comprising a receiver device, at a gateway entity of the communication system, configured to receive a request to perform a push operation towards a push destination entity, and connecting session device, at the gateway entity and the push destination entity, the connecting session device comprising setup means configured to set up a connecting session invoking a messaging session for delivering content to be pushed in the push operation towards the push destination entity.
  • the connecting session device comprises a messaging session device comprising a delivering means configured, at said gateway entity, to deliver said content to said push destination entity using said messaging session, and configured, at said push destination entity, to pickup said delivered pushed content;
  • said setup means of said connecting session device is configured to invoke the messaging session in the context of the connecting session;
  • said messaging session device is configured to conform to a Message Session Relay Protocol, MSRP, and the connecting session conforms to a Session Initiation Protocol, SIP, session;
  • MSRP Message Session Relay Protocol
  • SIP Session Initiation Protocol
  • the messaging session device is configured to encapsulate said content to be pushed in at least one MSRP request;
  • said delivering means comprises a configuration element configured to configure said messaging session by setting at least one messaging session parameter to report success of the push operation;
  • said delivering means, at the push destination entity further comprises a reporting element, push destination entity, configured to report, from the push destination entity (UA) towards the gateway entity (PPG) , success of the push operation in a report message of the messaging session, and wherein said delivering means, at the gateway entity, is configured to pickup said report message.
  • the arrangement further comprises a converter means, at the gateway entity, configured to convert the report message of the messaging session, into a push result message for further transmission;
  • said receiver device further comprises an analyzer configured to analyze the received request to perform a push operation, wherein said analyzing comprises at least whether the request to perform a push operation requests a connection oriented push operation for which a report of success is required, and said analyzer outputs a control signal supplied to a configuration element, which is configured to configure said delivering means of the messaging session device dependent on the control signal.
  • this object is for example achieved by a gateway entity for use in performing a push operation in a communication system, the gateway entity comprising a receiver device configured to receive a request to perform a push operation towards a push destination entity and a connecting session device comprising setup means configured to set up a connecting session invoking a messaging session for delivering content to be pushed in the push operation towards the push destination entity.
  • the messaging session device further comprises a delivering means configured to deliver said content to said push destination entity using said messaging session;
  • said setup means of said connecting session device is configured to invoke the messaging session in the context of the connecting session;
  • - said messaging session device is configured to conform to a Message Session Relay Protocol, MSRP, and the connecting session conforms to a Session Initiation Protocol, SIP, session; - said messaging session device is configured to encapsulate said content to be pushed in at least one MSRP request;
  • MSRP Message Session Relay Protocol
  • SIP Session Initiation Protocol
  • said delivering means comprises a configuration element configured to configure said messaging session by setting at least one messaging session parameter to report success of the push operation;
  • the gateway entity further comprises a converter means, configured to convert a report message of the messaging session into a push result message for further transmission;
  • said receiver device further comprises an analyzer configured to analyze the received request to perform a push operation, wherein said analyzing comprises at least whether the request to perform a push operation requests a connection oriented push operation for which a report of success is required, and said analyzer outputs a control signal supplied to a configuration element, which is configured to configure said delivering means of the messaging session device dependent on the control signal.
  • this object is for example achieved by a push destination entity for use in performing a push operation in a communication system, the push destination entity comprising a connecting session device comprising setup means configured to set up a connecting session invoking a messaging session for receiving content delivered in the push operation from a gateway entity of the communication system.
  • said messaging session device comprises a delivering means configured as a receiving means to pickup content pushed from a gateway entity;
  • said setup means of said connecting session device is configured to invoke the messaging session in the context of the connecting session;
  • said messaging session device is configured to conform to a Message Session Relay Protocol, MSRP, and the connecting session conforms to a Session Initiation Protocol, SIP, session;
  • MSRP Message Session Relay Protocol
  • SIP Session Initiation Protocol
  • said messaging session device is configured to receive pushed content encapsulated in at least one MSRP request
  • said configuration element is configured to detect at least one set messaging session parameter set to define a request to report success of the push operation
  • said delivering means further comprises a reporting element, responsive to said configuration element and configured to report, from the push destination entity towards the gateway entity, success of the push operation in a report message of the messaging session.
  • the above object is achieved, for example, by a computer program product comprising software code portions and performing the method steps as set out under any aspect above when the respective software code portions are executed on a respective computer processor at a gateway entity and a push destination entity.
  • the solution is transparent to the user and has hardly any impact to the terminal (push destination entity) application implementation.
  • This solution does not have a size restriction for push messages.
  • Fig. 1 shows in outline an arrangement for performing a push operation in a communication system, and in particular the signaling involved according to the method according to the present invention
  • Fig. 2 shows as a block circuit diagram a gateway entity for use in performing a push operation in a communication system according to the present invention
  • Fig. 3 shows as a block circuit diagram a push destination entity according to the present invention.
  • a communication device may for example be any device by means of which a user may access a communication system, or which may be accessed by a communication system in e.g. a push operation; this implies mobile as well as non-mobile devices and network systems, independent of the technology platform on which they are based; only as an example, it is noted that e.g. terminals operated according to principles standardized by the 3 rd Generation Partnership Project 3GPP and known for example as UMTS terminals are particularly- suitable for being used in connection with the present invention;
  • content as used in the present application in terms of content to be pushed is intended to mean at least one of audio data, video data, image data, text data, and meta data descriptive of attributes of the audio, video, image and/or text data, any combination thereof or even, alternatively or additionally, other data such as, as a further example, program code of an application program to be accessed/downloaded or control data for device management purposes; content may comprise further data of any Multipart Internet Mail Extension, MIME, type;
  • - method steps and/or devices likely to be implemented as hardware components at one of the entities are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS, CMOS, BiCMOS, ECL, TTL, etc, using for example ASIC components or DSP components, as an example;
  • any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention
  • - devices can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved.
  • Fig. 1 shows in outline an arrangement for performing a push operation in a communication system, and in particular the signaling involved according to the method according to the present invention.
  • FIG. 1 in horizontal direction, the entities are illustrated together with the respective signaling exchanged between them; in vertical direction, the sequence of signaling messages is illustrated. The sequence in time is also reflected by the numbering in the steps Sl to SIl denoting the respective signaling messages.
  • a push initiator entity PI denotes a push operation requesting entity. This can be co-located to e.g. an application server entity desiring to push a certain content, or receive respective trigger / control signals from a remotely located application entity. For the purpose of the present invention, any such distinction is not considered further. Rather, the push initiator is considered to be the source requesting to perform a push operation. The push request can be forwarded directly from the push initiator or via one or more intermediary nodes (not shown) to a push proxy gateway PPG.
  • a push proxy gateway PPG denotes a gateway entity involved in forwarding and/or relaying the content to be pushed via a communication system, of which the gateway forms a part of, towards a push destination entity.
  • a push destination entity is represented as a user agent UA and/or a client.
  • a user agent and/or client can reside in an application run on a terminal of a user.
  • a user agent is considered without a focus on the technical implementation of the terminal as such, i.e. whether the terminal is a fixed or wireless terminal and to which standard specification the terminal conforms (e.g. GPRS or UMTS) .
  • the subsequent description focuses on a specific embodiment which was considered by the present inventors to be a particularly enabled working embodiment and could thus be considered as a currently known "best mode" for practicing the present invention. The description of the specific embodiment, however, is not intended to exclude alternative implementations which may rely on different protocols not mentioned, but which preserve the functionality of and the advantages achieved by using the mentioned ones .
  • the push proxy gateway PPG Between the push proxy gateway PPG and the push initiator PI there is an interface conforming to the PAP protocol (see appendix, reference [PushPAP] for details) .
  • the PAP protocol sets out specific operations, which the push proxy gateway PPG follows in order to deliver the push content to the user's terminal.
  • the purpose of the Push submission is to deliver or to replace a push message from a Push Initiator PI to a push proxy gateway PPG.
  • the push proxy gateway PPG should then deliver the push message to a user agent UA (client) as a push destination entity in a user' s terminal device associated to the communication system such as a wireless network.
  • the Push message is sent in step Sl from the push initiator PI to the push proxy gateway PPG as a push request .
  • the push request message contains a control entity and a content entity, and may contain a capabilities entity.
  • An entity of a message is denoting a part or block of the message.
  • the control entity is e.g. an XML document (extended Markup Language) that contains control information (within the push-message) - (for details refer to reference [PushPAP] listed in the appendix) - for the push proxy gateway PPG to use in processing the message for delivery.
  • the content entity represents content to be sent to the push destination entity UA such as e.g. a wireless device .
  • the capabilities entity contains client capabilities assumed by the Push Initiator and is e.g. in the RDF format - (for details refer to reference [RDF] listed in the appendix) - as defined in the User Agent Profile - (for details refer to reference [UAPROF] listed in the appendix) .
  • the PPG may use the capabilities information to validate that the message is appropriate for the client.
  • the push proxy gateway may be configured to filter inappropriate push messages and to thereby prevent their delivery based on capabilities information.
  • Capabilities information may for example reside in indicating that a terminal (push destination entity) is multimedia enabled or not. Such processing is preferred in terms of avoiding the pushing of inappropriate push messages to a terminal's client. Nevertheless, optionally a push proxy gateway may also unconditionally deliver push messages .
  • Push submission processing includes four operations . The following three operations are performed in this order:
  • Push submission acceptance or rejection [0066] Each PAP push submission (i.e. push request message) received upon step Sl by the push proxy gateway PPG is either accepted or rejected. Acceptance or rejection is the result of the analysis performed by the push proxy gateway in step S2.
  • the gateway PPG should accept a PAP push submission if it might ultimately be delivered to the push destination entity such as an OTA client in this example of a wireless communication system.
  • the PPG must, however, reject any push submission (push message) containing a PAP push-message element that is not valid with respect to its document type definition (DTD) .
  • push message containing a PAP push-message element that is not valid with respect to its document type definition (DTD) .
  • DTD document type definition
  • the push method is determined based on information contained in e.g. the push request's control entity.
  • the analyzing comprises at least to analyze whether the request to perform a push operation requests a connection oriented push operation for which a report of success is required, and if so, pushing/delivering is configured accordingly responsive to said analyzing.
  • the result of analyzing is informed from the gateway PPG in step S3 as a push response to the push initiator PI .
  • This functionality delivers messages to the OTA client (user agent UA/ client at a terminal) as a push destination entity.
  • This functionality comprises selection and/or activation of a determined Push OTA (see reference [PushOTA] listed in appendix for details) protocol (e.g. based on determination/analysis in step S2), selection of confirmed or unconfirmed push mode, push message delivery, and network bearer selection. Above mentioned selection steps are illustrated as forming part of step S2 illustrated in Fig. 1.
  • the push proxy gateway PPG sends a PAP result response to the PI in step S3, as mentioned above.
  • the push proxy gateway PPG sends an SIP INVITE request to the push destination entity UA.
  • SIP Session Initiation Protocol
  • SIP INVITE contains a session description protocol SDP entity describing (e.g. properties of) an MSRP media stream and declaring support for a number of MIME types that are applicable (e.g., this could be a generic OMA SIP PUSH MIME type or a specific one, such as Device Management DM) .
  • the client UA accepts the session by returning in step S5 a SIP 200 OK message.
  • the push proxy gateway PPG in turn acknowledges the reception of the SIP 200 OK in a step S6 ("ACK") .
  • the push proxy gateway PPG sends a request to push content using Message Session Relay Protocol MSRP with SIP.
  • the request is represent by a so-called object to be pushed over the air interface using e.g. SIP as a connecting session.
  • SIP Message Session Relay Protocol
  • the MSRP SEND request contains a special MIME type in the Content-Type header, different of text/plain or text/html. For example, it could be application/oma-sip-push+xml .
  • Such MIME type is an example of an above mentioned object: an encapsulation in SIP protocols of the push XML document.”
  • the push proxy gateway PPG in step S7, encapsulates such object in the MSRP SEND message (encapsulating is done in at least one MSRP send message) . It also configures the messaging session by setting the MSRP header Report-Success to "yes" in order to request confirmation of delivery.
  • the control entity of the push message is a MIME body part, which holds e.g. an XML document containing one PAP element as defined in reference [PushPAP] .
  • the push-message element carries the quality-of-service attribute, which gives the push proxy gateway PPG specific instructions for delivery of the message.
  • the QoS attribute is translated into over-the-air SIP protocol operation methods .
  • the actual content to be pushed is delivered step S7.
  • the MSRP SEND request includes the object / content to be pushed. Also, more than one MSRP SEND request carrying the content can be sent. For example, large push contents can be split and pushed in consecutive MSRP SEND messages. This involves using the MSRP feature named "message-chunking enabled". In any case, the object
  • (content) to be pushed is encapsulated in at least one such MSRP SEND request.
  • the client UA sends an MSRP 200 response in step S8. This cannot be used as a confirmation of delivery, because if it had been an MSRP relay in between the gateway PPG and the UA, the MSRP 200 response would have been generated by the MSRP relay rather than by the UE.
  • the client UA sends in a subsequent step S9 an MSRP REPORT message to the gateway PPG. This constitutes the confirmation of delivery of the sent MSRP message containing the pushed PUSH object.
  • the gateway PPG converts the success report and sends a corresponding delivery result notification message, step SlO, if the message is accepted and the push initiator PI requested message delivery- notification.
  • the "resultnotification-response” is sent in step SIl by the Push Initiator PI to confirm receipt of the "resultnotification-message" of step SlO.
  • the present invention concerns a method for performing a push operation in a communication system.
  • the method basically comprises the steps of receiving, Sl, at a gateway entity PPG of the communication system, a request to perform a push operation towards a push destination entity UA. Further, the method involves setting up,S4, a connecting session invoking a messaging session for delivering content to be pushed in the push operation towards the push destination entity UA. Said content to be pushed is received in said request Sl to perform a push operation (together with control information for the push operation) .
  • the method further comprises a step of delivering, S7, said content to said push destination entity UA using said messaging session.
  • the messaging session is invoked within the context of the connecting session.
  • the messaging session is a Message Session Relay Protocol, MSRP, session and the connecting session is a Session Initiation Protocol, SIP, session.
  • Any content to be pushed is encapsulated in at least one MSRP request.
  • the delivering step comprises configuring said messaging session by setting at least one messaging session parameter to report success of the push operation.
  • the receiving step further comprises a step of analyzing, S2, the received request to perform a push operation, and said delivering step, S7, is configured responsive to said analyzing.
  • the analyzing comprises at least to analyze whether the request to perform a push operation requests a connection oriented push operation for which a report of success is required.
  • the method further comprises a step of reporting, S9, from the push destination entity UA towards the gateway entity (PPG) , success of the push operation in a report message of the messaging session. Additionally, the method may further comprise a step of converting, at the gateway entity PPG, the report message of the messaging session into a push result message for further transmission, SlO, responsive to the request received in the receiving step Sl.
  • the arrangement for performing a push operation in a communication system therefore comprises a receiver device, at a gateway entity PPG of the communication system, which is configured to receive a request to perform a push operation towards a push destination entity UA, and a connecting session device, at the gateway entity and the push destination entity.
  • the connecting session device comprises setup means configured to set up a connecting session invoking a messaging session for delivering content to be pushed in the push operation towards the push destination entity UA.
  • a setup means at the gateway entity may request setup of a connecting session invoking a messaging session and a setup means at the push destination entity may accept such request. Both setup means therefore cooperate in setting up a messaging session.
  • the setup means of said connecting session device is configured to setup the connecting session invoking the messaging session in the context of the connecting session. This applies for the gateway entity as well as for the destination entity.
  • the messaging session device is configured to conform to a Message Session Relay Protocol, MSRP, and the connecting session conforms to a Session Initiation Protocol, SIP, session.
  • the content to be pushed is received at said receiver device in said request to perform a push operation.
  • the messaging session device further comprises a delivering means configured, at said gateway entity, to deliver said content to said push destination entity UA using said messaging session, and configured, at said push destination entity, to pickup said delivered pushed content .
  • the delivering means comprises a configuration element configured to configure said messaging session by setting at least one messaging session parameter to report success of the push operation.
  • the configuration element at the gateway entity may request/initiate configuration of a messaging session and the configuration element at the push destination entity may accept such request. Both configuration elements therefore cooperate in configuring a messaging session.
  • the receiver device further comprises an analyzer configured to analyze the received request to perform a push operation. The analyzer analyzes at least whether the request to perform a push operation requests a connection oriented push operation for which a report of success is required. The analyzer outputs a control signal supplied to said configuration element, which is configured to configure said delivering means of the messaging session device dependent on the control signal.
  • the delivering means, at the push destination entity further comprises a reporting element, configured to report, from the push destination entity UA towards the gateway entity PPG, success of the push operation in a report message of the messaging session; and the delivering means, at the gateway entity, is configured to pickup said report message, i.e. a delivered report message is received at the push gateway entity.
  • the arrangement further comprises a converter means, at the gateway entity, configured to convert the report message of the messaging session, into a push result message for further transmission.
  • the further transmission can be directed to the push initiator PI, if requested in the push request message, directly or via one or more intermediary nodes .
  • the gateway entity as well as the push destination entity are described as comprising a delivering means. This is intended to mean that the gateway entity's delivering means delivers/sends pushed content to the destination device's delivering means; while the destination entity' s delivering means is configured to receive (pickup) such pushed content. Likewise, a report message is delivered/sent from the destination entity's delivering means (reporting element) to the gateway entity's delivering means; the gateway entity's delivering means is thus configured to receive (pickup) such report message .
  • Fig. 2 shows those elements and/or parts of a push proxy gateway entity related to the present invention.
  • the gateway entity is part of the above described arrangement and configured to conform to the method disclosed further above.
  • Other constituents of a push proxy gateway not directly related to the present invention are omitted from the illustration.
  • the gateway entity PPG is configured for use in performing a push operation in a communication system.
  • the gateway entity PPG comprises in relation to the present invention a receiver device 21 configured to receive a request to perform a push operation.
  • the request is received from a push operation requesting entity (e.g. an application) or push initiator PI.
  • the request is received either directly or via one or more intermediary nodes .
  • the request is internally processed in the receiver device 21 (in an analyzer 22 to be described later) and passed to a connecting session device 24 configured to set up a connecting session for a connection from the gateway entity PPG towards a push destination entity UA of the communication system, i.e. between these entities.
  • the connecting session device 24 is merely illustrated to comprise a setup means 28 configured to setup a connecting session invoking a messaging session.
  • the messaging session is handled by a messaging session device 25 configured to establish a messaging session within the context of the connecting session, for delivering content to be pushed in the push operation towards the push destination entity UA.
  • the connecting session device need not actually comprise the messaging session device, as long as the devices cooperate with each other to realize the functionality involved by the present invention.
  • the messaging session device 25 comprises a delivering means 27.
  • the delivering means 27 comprises a configuration element 26 configured to configure said messaging session by setting at least one messaging session parameter to report success of the push operation.
  • the gateway entity PPG further comprises a converter means 23 configured to convert a report of success message of the messaging session (received from the push destination device) into a result message for further transmission from the push proxy gateway entity PPG towards the push operation requesting entity, e.g. PI, either directly or via one or more intermediary nodes .
  • a converter means 23 configured to convert a report of success message of the messaging session (received from the push destination device) into a result message for further transmission from the push proxy gateway entity PPG towards the push operation requesting entity, e.g. PI, either directly or via one or more intermediary nodes .
  • the receiver device 21 further comprises, for internal processing purposes mentioned above, an analyzer 22 configured to analyze the received request to perform a push operation.
  • the analyzer 22 outputs a control signal ctrll supplied to the messaging session device 25 at said gateway entity, more precisely to the configuration element 26 thereof.
  • Dependent on the control signal said messaging session device 25 configures said messaging session by setting at least one messaging session parameter to report success of the push operation.
  • Configuring is realized by the configuration element 26.
  • the configuration element 26 may optionally configure the messaging session independent of the control signal so as to report success of the push operation. Criteria for analysis and configuration are as described above in relation to the method aspect and therefore not repeated here.
  • the push content as well as the report message are carried within the messaging session invoked and/or established in the context of the connecting session , as illustrated in Fig. 2, to and from the push destination entity UA.
  • the push message (request) is received e.g. from the push initiator PI and the result message (converted report message) is transmitted to e.g. the push initiator PI .
  • the messaging session device is configured to conform to a Message Session Relay Protocol, MSRP, and the connecting session conforms to a Session Initiation Protocol, SIP, session.
  • Fig. 3 shows those elements and/or parts of a push destination entity UA related to the present invention. This entity is also part of the above described arrangement and configured to conform to the method disclosed further above. Other constituents of the push destination entity UA not directly related to the present invention are omitted from the illustration.
  • the push destination entity UA is configured for use in performing a push operation in a communication system.
  • the push destination entity UA comprises a connecting session device 33 comprising setup means 35 configured to set up a connecting session invoking a messaging session for receiving content delivered in the push operation from a gateway entity of the communication system, i.e. the connecting/messaging sessions are between these entities.
  • the connecting session device 33 is illustrated as further comprising a messaging session device 34 handling the messaging session invoked within the context of the connecting session for delivering content to be pushed in the push operation towards the push destination entity UA.
  • the connecting session device need not actually comprise the messaging session device, as long as the devices cooperate with each other to realize the functionality involved by the present invention.
  • the messaging session device 34 comprises a delivering means 36 which comprises a configuration element 37configured to configure said messaging session by setting at least one messaging session parameter to report success of the push operation.
  • the setup means at the gateway entity may request setup of a connecting session invoking a messaging session and the setup means at the push destination entity may accept such request. Both setup means therefore cooperate in setting up a connecting session invoking a messaging session.
  • the setup means of said connecting session device is configured to invoke the messaging session in the context of the connecting session. This applies for the gateway entity as well as for the destination entity.
  • the messaging session device is configured to conform to a Message Session Relay Protocol, MSRP, and the connecting session conforms to a Session Initiation Protocol, SIP, session.
  • the push destination entity UA further comprises a reporting element 32 (associated to the delivering means 36) configured to report, from the push destination entity UA towards the gateway entity PPG, success of the push operation in a report message.
  • the reporting element 32 is controlled by a signal ctrl2 supplied thereto from the configuration element 37 of the delivering means 36 of the messaging session device 34.
  • pushed content received at the push destination device UA is passed internally (via the messaging session device / connecting session device) to a push content output device 31.
  • This can be any appropriate memory and/or output device such as a display or loudspeaker enabling an end-user of the device/terminal to perceive the pushed content (i.e. reading or hearing it, dependent on the type of content pushed) .
  • the content is for example terminal configuration data or settings (e.g. device management data mentioned above)
  • the content is not intended to end users but to terminal internal purposes; such content is rather passed to a memory and used for changing device settings maintained at that or another memory or memory partition.
  • pushed content is delivered to the respective application to which the pushed content refers and/or belongs .
  • This invention addresses the connection- oriented type of push operations, where a push proxy gateway entity PPG
  • - is aware of the terminal's (push destination entity's) capabilities ; - uses user plane to push large amount of content data to deliver them to the push destination entity,
  • the push proxy gateway PPG uses in a particular embodiment the Message Session Relay Protocol (MSRP) [IETF-MSRP] with SIP [RFC3261] .
  • MSRP Message Session Relay Protocol
  • SDP session Description Protocol
  • the push proxy gateway PPG sends one or more MSRP SEND requests (see step S7 in Fig. 1) that contains PUSH objects identified with a particular MIME type.
  • MSRP SEND requests see step S7 in Fig. 1
  • this MIME type will be different on a per PUSH application, so that a Device Management application pushing content may use a different MIME type content than an MMS application pushing content.
  • the push proxy gateway PPG may use the MSRP SEND request with the message-chunking enabled.
  • delivery confirmation i.e. a report on the success of delivered pushed contents
  • Such setting can be fixed for all push contents or configured dependent on a push message (e.g. push application type, pushed content type, or other criteria)
  • a push message e.g. push application type, pushed content type, or other criteria
  • MSRP see for details reference [IETF-MSRP] in the appendix is chosen as an example for the purpose of describing the present invention only, however, any other suitable text-based, connection-oriented protocol for exchanging arbitrary content such as MIME content could be chosen within the framework of the present invention, as long as it preserves the MSRP functionalities exploited /relied on in connection with the present invention.
  • the MSRP sessions are typically arranged using SIP the same way a session of audio or video media is setup.
  • MSRP offers the capability of message chunking, where the push messages are divided up into smaller size to be transported to the client device (push destination entity) .
  • MSRP provides the transaction and report mechanism.
  • MSRP is a text-based, connection-oriented protocol for exchanging arbitrary (binary) MIME content, especially instant messages. MSRP works and is used with SIP.
  • MSRP sessions are typically arranged using SIP the same way a session of audio or video media is setup.
  • One SIP user agent PPG
  • PPG sends to the other (UA) a SIP invitation containing an offered session-description which includes a session of MSRP.
  • the receiving SIP user agent can accept the invitation and include an answer session- description which acknowledges the choice of media.
  • the PPG' s session description contains an MSRP URL that describes where the PPG is willing to receive MSRP requests from the UA, and vice-versa.
  • MSRP defines two request types, or methods. SEND requests are used to deliver a complete message or a chunk (a portion of a complete message) , while REPORT requests report on the status of an earlier SEND request.
  • the PPG When the PPG receives the UA' s answer, the PPG checks to see if it has an existing connection to the UA. If not, PPG opens a new connection to the UA using the URL the UA provided in the SDP. The PPG then delivers a SEND request to the UA with its initial message, and the UA replies indicating that the PPG' s request was received successfully.
  • connection session there are two sessions in this invention: one e.g. in SIP signaling as a connecting session; the other is MSRP session as a messaging session.
  • the connecting session has the purpose of invoking and/or establishing the messaging session, while the messaging session alone would be insufficient, as it always needs a signaling (connecting) session.
  • MSRP and SIP are independent, i.e. the packets forwarded under SIP don't follow the same path as the MSRP packets.
  • MSRP follows the user plane, whereas SIP follows the signaling plane, and traditionally these two planes follow separate paths.
  • MSRP is comparable, from the user plane point of view, to RTP.
  • RTP requires SIP/SDP to establish the session, and so does MSRP.
  • MSRP unlike RTP, is text based (looks like SIP sometimes), and MSRP relays are located in the user plane path (unlike RTP that is end-to-end oriented). So the SIP stack is SIP (SDP) /UDP or SIP(SDP) /TCP.
  • the brackets in SDP indicate "piggybacked in SIP".
  • the MSRP stack is "just" MSRP/TCP. (Similarly (although not applicable to this invention) , the RTP stack would look like RTP/UDP.)
  • SIP connection setup
  • MSRP MSRP is on top of TCP. It does not matter if the transport layer is different since there are two different sessions.
  • SIP requests and MSRP messages do not follow the same path. SIP requests are routed via SIP proxies, however MSRP messages are routed via some kind of MSRP relay elements .
  • SIP includes SDP body which contains MSRP details for invoking MSRP messaging session, and the purpose of MSRP details is to invoke MSRP session between UE and PPG.
  • Both, the gateway PPG and the destination device UA comprise the connecting session device and the messaging session device including delivering means and configuration element.
  • the respective means cooperate in a handshake procedure such that a request issued by e.g. the PPG is processed/accepted at the UA and/or vice versa.
  • the processing performed at the gateway side is therefore to a certain extent to be regarded as being complementary to those performed at the destination device side.
  • the device, means and elements forming part of the gateway and/or the destination entity can be implemented in hardware or software. When implemented in software, the block circuit diagram represent software modules of a computer program product.
  • the gateway as well as the destination device then comprise a respective computer processor.
  • the present invention also relates to a computer program product comprising software code portions and performing the method steps as set out under any aspect of the preceding method description, when the respective software code portions are executed on a respective computer processor at a gateway entity and a push destination entity.
  • the present invention relates to an arrangement and method for performing a push operation in a communication system.
  • the present invention concerns an involved gateway entity and push destination entity.
  • the arrangement comprises a receiver device, at a gateway entity of the communication system, configured to receive a request to perform a push operation towards a push destination entity, and comprises a connecting session device, at the gateway entity and the push destination entity.
  • the connecting session device comprises setup means configured to setup a connecting session invoking a messaging session for delivering content to be pushed in the push operation towards the push destination entity.
  • the PPG may implement network access-control policies about who is able to gain access to the network, that is, who is able to push content and who is not, under which circumstances, and so on.
  • the PI and the PPG 200 may communicate between each other using a push access protocol (PAP) as summarized in the document WAP-250- PushArchOverview-20010703-a.
  • PAP push access protocol
  • the PAP supports push submission, result notification, push cancellation, push replacement, status query and client capabilities query.
  • a message comprising a control entity, a content entity and optionally a capability entity is sent from the PI 24 to the PPG 22.
  • the control entity contains the delivery instructions for the PPG 22.
  • the control entity may be an extensible markup language (XML) document.
  • the PI or another push server, may be a separate network entity or a single network entity with the push entity, such as with the PPG 200.
  • the push server may be provided in a device management server, in a multimedia messaging service center (MMSC) or in another appropriate network entity.
  • MMSC multimedia messaging service center
  • the Figures are only an example showing only one communication system in connection with one communication device (push destination entity UA) , one push proxy gateway PPG together with one push initiator (application server) .
  • the number and type of entities concerned in a communication system may differ substantially from that which is shown.
  • the communication networks typically further comprise various switching and other control entities and gateways for enabling the communication for interfacing a single communication network with one or more communication networks .
  • control entities are not shown in the Figures.
  • a communication system is typically arranged to serve a plurality of communication devices.
  • a communication device may have several simultaneous communication sessions, for example a number of session initiation protocol (SIP) sessions and activated packet data protocol (PDP) contexts.
  • Communication devices may be connected to the communication system from the same or different networks. Communication devices may access the communication system via any appropriate access system. Examples may include, but are not limited to, radio access networks, e.g.
  • a mobile communication system may logically be divided into a radio access network (RAN) and a core network (CN) .
  • the communication device UA may access the communication network 10 via an access entity (not shown) of the RAN.
  • the communication device 12 may, for example, wirelessly transmit and receive radio signals via a radio interface to and from a transceiver network element connected to the access entity.
  • the transceiver network element may wirelessly transmit and receive radio signals to and from the first communication device UA.
  • Services over wireless communication networks may use capabilities of, for example, the Internet Protocol multimedia (IM) core network subsystem (IMS) .
  • the IMS enables IP connections for a communication device and other parties to the communication, such as other communication devices or entities associated with the network.
  • the third generation partnership project (3GPP) has defined use of the GPRS for offering IP connectivity to IMS services.
  • the 3GPP has further defined a call control protocol for use in the IMS based on a session initiation protocol (SIP) and an associated session description protocol (SDP) .
  • SIP session initiation protocol
  • SDP session description protocol
  • the communication system is a SIP controlled system/network.
  • the communication network is provided at least in part by the IMS.
  • a PDP context may include a radio bearer provided between a communication device and a radio network controller, a radio access bearer provided between the communication device UA, the radio network controller and a serving GPRS support node (SGSN) , and switched packet data channels provided between the SGSN and a gateway GPRS support node (GGSN) .
  • SGSN serving GPRS support node
  • GGSN gateway GPRS support node
  • Each PDP context usually provides a communication pathway between a particular communication device and the GGSN and, once established, can typically carry multiple flows. Each flow normally represents, for example, a particular service and/or a media component of a particular service.
  • the PDP context therefore often represents a logical communication pathway for one or more flow across the network.
  • radio access bearers To implement the PDP context between the communication device and the SGSN, radio access bearers (RAB) need to be established which commonly allow for data transfer for the communication device.
  • RAB radio access bearers
  • the implementation of these logical and physical channels is known to those skilled in the art and is therefore not discussed further herein.
  • the communication device UA used by an end-user for accessing the communication system may be any appropriate communication device, also called terminal.
  • Examples may comprise user equipment UE, a mobile station MS, a cellular phone, a personal digital assistant PDA and a personal computer PC. Further examples may comprise any other equipment operable according to SIP and preferably another suitable network or transport protocol, such as the WSP, the HTTP or the TCP.
  • a typical communication device UA may be provided with an antenna or other such transceiver and receiver device for wirelessly receiving and transmitting signals from and to a transceiver network element of a wireless communication system.
  • a communication device may also be provided with a display and a speaker. The operation of a communication device may be controlled by means of a suitable user interface comprising control means, such as a keypad, voice commands, touch sensitive screen or pad, or combinations thereof, or the like.
  • a communication device is typically provided with a processor and memory means as well as software and applications operating the device and enabling operation with other entities.
  • Software which is able to request services from other entities in a communication system, may be called a client.
  • the session initiation protocol is an application layer control protocol defined in document RFC 3261 "SIP: Session Initiation Protocol", June 2002, by the Internet Engineering Task Force (IETF) for creating, modifying and terminating sessions with one or more participants.
  • IETF Internet Engineering Task Force
  • a user connected to a SIP base communication system may communicate with various entities of the communication system based on standardized SIP messages. Communication devices or user who run certain applications on the communication devices are registered with the SIP backbone so that an invitation to a particular session can be correctly delivered to these end points.
  • SIP provides a registration mechanism for devices and users and it applies mechanisms such as location servers and registrars to route the session invitations appropriately.
  • the details of a session such as the type of media, codec or sampling rate, are not described in SIP headers. Rather, a body of a SIP message may contain a description of a session, encoded in an appropriate protocol format.
  • An example of such protocol format comprises session description protocol (SDP) defined in document RFC 2327 "SDP: Session Description Protocol", April 1998.
  • SDP session description protocol
  • URI Uniform Resource Identifiers
  • a URI may point to a registered user identity of an individual user, but may identify also other entities in the network, such as service provider servers or other types of resources .
  • CSCF Call/Session Control Function
  • HSS Home Subscriber Server
  • I-CSCF Interrogating CSCF
  • IMS IP Multimedia Subsystem
  • IP Internet Protocol
  • OTA-HTTP Push Over-the-Air Protocol, a variant of HTTP
  • PAP Push Access Protocol, a variant of HTTP
  • PPG Push Proxy Gateway
  • S-CSCF Serving CSCF
  • SIP Session Initiation Protocol
  • UE User Equipment
  • WSP Wireless Session Protocol
  • Push Proxy Gateway Service WAP ForumTM, WAP-249-PPGService,

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un agencement et un procédé permettant d'effectuer une opération de distribution dans un système de communication. L'invention concerne également une entité à passerelle impliquée et une entité de destination de la distribution. L'agencement comprend un dispositif récepteur, au niveau de l'entité à passerelle du système de communication, conçu pour recevoir une demande d'exécution d'une opération de distribution à une entité de destination de la distribution et comprenant un dispositif de session de connexion, au niveau de l'entité à passerelle et de l'entité de destination de la distribution. Le dispositif de session de connexion comprend des moyens de réglage permettant de régler une session de connexion invoquant une session de messagerie permettant de fournir le contenu à distribuer dans l'opération de distribution à l'entité de destination de la distribution.
PCT/IB2006/050849 2005-04-11 2006-03-20 Procede et entites permettant d'executer une session de distribution dans un systeme de communication WO2006109202A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP05007881.5 2005-04-11
EP05007881 2005-04-11
US11/155,727 US20060230154A1 (en) 2005-04-11 2005-06-20 Method and entities for performing a push session in a communication system
US11/155,727 2005-06-20

Publications (1)

Publication Number Publication Date
WO2006109202A1 true WO2006109202A1 (fr) 2006-10-19

Family

ID=36689469

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2006/050849 WO2006109202A1 (fr) 2005-04-11 2006-03-20 Procede et entites permettant d'executer une session de distribution dans un systeme de communication

Country Status (1)

Country Link
WO (1) WO2006109202A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009027532A1 (fr) * 2007-08-31 2009-03-05 Streamezzo Procédé de création d'au moins un contenu, procédé d'optimisation du fonctionnement d'un terminal de télécommunications, terminal, programme d'ordinateur et signal correspondants.
US9247018B2 (en) 2010-07-30 2016-01-26 Huawei Technologies Co., Ltd. Method and apparatus for cooperation between push devices
US9641955B2 (en) 2010-10-12 2017-05-02 Thomson Licensing Transmitting information

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1280314A2 (fr) * 2001-07-26 2003-01-29 Openwave Systems Inc. Procédé et dispositif pour délivrer sélectivement des notifications aux utilisateurs de plusieurs dispositifs par un réseau
FR2842681A1 (fr) * 2002-07-19 2004-01-23 France Telecom Procede et systeme d'avertissement et de diffusion d'informations par un reseau public de transmission de donnees numeriques

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1280314A2 (fr) * 2001-07-26 2003-01-29 Openwave Systems Inc. Procédé et dispositif pour délivrer sélectivement des notifications aux utilisateurs de plusieurs dispositifs par un réseau
FR2842681A1 (fr) * 2002-07-19 2004-01-23 France Telecom Procede et systeme d'avertissement et de diffusion d'informations par un reseau public de transmission de donnees numeriques

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Support of Push service (Release 5); 3GPP TR 23.875", ETSI STANDARDS, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, SOPHIA-ANTIPO, FR, no. V510, March 2002 (2002-03-01), XP014021954, ISSN: 0000-0001 *
CAMPBELL B ET AL: "The Message Session Relay Protocol; draft-ietf-simple-message-session s-10.txt;", IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, vol. simple, no. 10, 20 February 2005 (2005-02-20), XP015027600, ISSN: 0000-0004 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009027532A1 (fr) * 2007-08-31 2009-03-05 Streamezzo Procédé de création d'au moins un contenu, procédé d'optimisation du fonctionnement d'un terminal de télécommunications, terminal, programme d'ordinateur et signal correspondants.
FR2920625A1 (fr) * 2007-08-31 2009-03-06 Streamezzo Sa Procede de generation d'au moins un contenu, procede d'optimisation du fonctionnement d'un terminal de radiocommunication, terminal, programme d'ordinateur et signal correspondants
US9247018B2 (en) 2010-07-30 2016-01-26 Huawei Technologies Co., Ltd. Method and apparatus for cooperation between push devices
US9641955B2 (en) 2010-10-12 2017-05-02 Thomson Licensing Transmitting information

Similar Documents

Publication Publication Date Title
US20060230154A1 (en) Method and entities for performing a push session in a communication system
US7274943B2 (en) Service subscription in a communication system
US20060179115A1 (en) Controlling push operation in a communication system
KR100886548B1 (ko) 인터넷 프로토콜 멀티미디어 서브시스템 네트워크에서단말의 성능 정보를 전달하기 위한 방법 및 시스템
US8327024B2 (en) System and method for SMS/IP interoperability
US20100087215A1 (en) Method, system, and message service interworking module for implementing message service interworking
US7480915B2 (en) WV-IMS relay and interoperability methods
US8102839B2 (en) System, apparatus, and method for establishing circuit-switched communications via packet-switched network signaling
US20060133335A1 (en) Establishing a push session in a communication system
US8195168B2 (en) Mechanism for controlling a transmission of data messages to user equipment by an external gateway
US20040103157A1 (en) Store-and-forward server and method for storing and forwarding for instant messaging service implemented in IP multimedia core network subsystem (IMS)
EP2028815A1 (fr) Procédé et système de délivrance de données de services de messagerie
US20050083909A1 (en) System, apparatus, and method for establishing circuit-switched communications via packet-switched network signaling
US20050044159A1 (en) Messaging system
WO2006067264A1 (fr) Partage de contenu dans un systeme de communication
KR20070077419A (ko) ＩＭＳ 도메인을 통한 실시간 서비스를 포함하는 ＶｏＩＰ단말의 호 요청을 ＣＳＩ 단말이 처리하는 방법 및 장치
TW200526055A (en) Sessions in a communication system
WO2006109202A1 (fr) Procede et entites permettant d'executer une session de distribution dans un systeme de communication
KR101043696B1 (ko) 인스턴트 메시지 서비스 시스템 및 이동통신 단말기, 및 그 서비스방법
EP2136517B1 (fr) Livraison de messages courts
KR20080034072A (ko) Ｓｉｐ기반의 전송 메시지를 이용한 이종 메시지의 전송방법 및 이를 위한 사용자 장치
KR100429548B1 (ko) 3ｇｐｐ ｉｍｔ-2000 패킷망의 착신서비스 시스템 및 방법
EP1839196A1 (fr) Controle d'acces a un serveur d'information mobile dans un systeme de communication
EP1672867A1 (fr) Méthode pour le transfert rapide et fiable d'une grande quantité de données entre utilisateurs radio mobiles impliqués dans une session SIP
Atanasov et al. Integrating Non Call-Related User Interactions in SIP Environment

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

NENP Non-entry into the national phase

Ref country code: RU

WWW Wipo information: withdrawn in national office

Country of ref document: RU

122 Ep: pct application non-entry in european phase

Ref document number: 06727682

Country of ref document: EP

Kind code of ref document: A1

WWW Wipo information: withdrawn in national office

Ref document number: 6727682

Country of ref document: EP