Early data channel establishment schemes

Abstract

A method of wireless communication is provided. The method comprises receiving, by a user device in a first network configured to be in communication with a second network, a session description protocol (SDP) offer requesting an early data channel (DC) during a session initiation protocol (SIP) session establishment procedure; and establishing the early DC between the user device and the second network before the SIP session is successfully established.

Description

EARLY DATA CHANNEL ESTABLISHMENT SCHEMESTECHNICAL FIELD

[0001] This document relates to systems, devices and techniques for wireless communications.BACKGROUND

[0002] Wireless communication technologies are moving the world toward an increasingly connected and networked society. The rapid growth of wireless communications and advances in technology has led to greater demand for capacity and connectivity. Other aspects, such as energy consumption, device cost, spectral efficiency, and latency are also important to meeting the needs of various communication scenarios. In comparison with the existing wireless networks, next generation systems and wireless communication techniques need to provide support for an increased number of users and devices, as well as support an increasingly mobile society.SUMMARY

[0003] Various methods and apparatus for establishing an early data channel are provided.

[0004] In one example aspect, a method of wireless communication is disclosed. The method comprises receiving, by a user device in a first network configured to be in communication with a second network, a session description protocol (SDP) offer requesting an early data channel (DC) during a session initiation protocol (SIP) session establishment procedure; and establishing the early DC between the user device and the second network before the SIP session is successfully established.

[0005] In another example aspect, a method of wireless communication is disclosed. The method comprises determining, by an IP multimedia subsystem (IMS) application server in a network, that an early data channel (DC) is required for a session initiation protocol (SIP) session, the early DC refers to a data channel established before the SIP session is successfully established; sending, to a data channel signaling function in the network, a first message that requests to reserve media resource information for the early DC; and sending, to a call session control function in the network, a session description protocol (SDP) offer requesting the early DC.

[0006] In another example aspect, a method of wireless communication is disclosed. The method may comprise receiving, by a data channel signaling function and from a multimedia subsystem (IMS) application server, a request to reserve media resource information for an early data channel (DC) that refers to a data channel established before a session initiation protocol (SIP) session is successfully established; reserving media resource information for the early DC based on the request; and sending, to the IMS application server, a media resource instruction for the early DC that instructs the IMS application server to set up the early DC based on the media resource information.

[0007] In yet another example aspect, a wireless communications apparatus comprising at least one processor is disclosed. The at least one processor is configured to cause the wireless communication apparatus to implement methods described herein.

[0008] In another example aspect, the various techniques described herein may be embodied as processor-executable code and stored on a computer-readable program medium.

[0009] The details of one or more implementations are set forth in the accompanying drawings, and the description below. Other features will be apparent from the description and drawings, and from the claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1 shows an example of an IP Multimedia Subsystem (IMS) architecture supporting data channel service.

[0011] FIG. 2 shows an example of a procedure flow for establishing a bootstrap data channel in a person-to-person (P2P) use case.

[0012] FIG. 3 shows an example of a procedure flow for establishing an application data channel in a person-to-person use case.

[0013] FIG. 4 shows an example of an early DC establishment procedure towards a terminating UE based on some implementations of the disclosed technology.

[0014] FIG. 5 shows an example of an early DC establishment procedure towards an originating UE in P2A procedure based on some implementations of the disclosed technology.

[0015] FIG. 6 shows an example of an early DC establishment procedure towards an originating UE in P2P procedure based on some implementations of the disclosed technology.

[0016] FIG. 7 shows example operations of a terminating network for deciding an early DC and reserving a media resource for the early DC based on some implementations of the disclosed technology.

[0017] FIG. 8 is a block diagram of an example of a wireless communication apparatus based on some implementations of the disclosed technology.

[0018] FIGS. 9-11 are example flowcharts of a wireless communication method based on some implementations of the disclosed technology.DETAILED DESCRIPTION

[0019] The disclosed technology provides implementations and examples for early data channel establishment during an IMS session.

[0020] IMS data channel is a quickly developing new technology introduced to IMS, providing innovative opportunity to thrive the IMS ecosystem. The IMS data channel is a kind of transmission container that allows dynamically download service applications to the user terminal where the service applications are organized in script based applets (e.g., HTML + CSS + Javascript + JSON) . Such a light weight applet can provide real interactive user experience, high definition audio / voice content, and Augmented Reality (AR) content if needed.

[0021] A new trend raised with IMS data channel is to feasibly move most legacy IMS session features and supplementary services to IMS data channel by implementing certain data channel applications as replacement. One typical requirement is the early media exchange via data channel which provides more diversified and efficient method to present the early media.

[0022] Early media is commonly exchanged to deliver supplementary information to the calling / called party (e.g., play audio / video to the calling party to display the called party information, or via verse) before the SIP session is fully established (e.g., before sending or receiving “200 OK” which refers to the response indicating that the SIP session has been successfully established and is ready for communication to begin) . This can occur during the session's provisional phase when a 1xx response (e.g., “180 Ringing, ” “183 Session Progress” ) is exchanged.

[0023] To support new requirements, it requires to establish early data channel (i.e., early DC) before SIP session is successfully confirmed (e.g., before sending or receiving “200 OK” ) . For example, an early DC is urged to be established to play early media so that to make it as a replacement of legacy mechanism for early media exchange in IMS session. Currently, the IMS data channel is established after sending or receiving “200 OK” and cannot support the new requirement.

[0024] This disclosure provides a method to establish early DC before a SIP session successfully established (e.g., before sending or receiving “200 OK” ) to support the new requirement especially for the early media exchange.

[0025] FIG. 1 shows the IMS architecture with data channel support. In the above architecture shown in FIG. 1, there are the following network functions:

[0026] 1) UE (User Equipment) .

[0027] 2) CSCF (Call Session Control Function) : A general term for a functional entity within an IMS core network that can act as Proxy CSCF (P-CSCF) , Serving CSCF (S-CSCF) , or Interrogating CSCF (I-CSCF) .

[0028] 3) P-CSCF (Proxy CSCF) : The first contact point for the user equipment (UE) within the IMS core network.

[0029] 4) S-CSCF (Serving CSCF) : The entity in the IMS core network that handles the call session states.

[0030] 5) HSS (Home Subscriber Server) : A common functional entity to both the circuit switched and packet switched mobile domains in 3GPP / 3GPP2. The HSS is the master database that supports the IMS network entities. It is the entity containing the subscription-related information to support the network entities and performs authentication and authorization of the user and can provide information about the subscriber's location and IP information.

[0031] 6) PCF (Policy Control Function) : The PCF provides QoS policy rules for an IMS session.

[0032] 7) IMS AS (IMS Application Server) : The IMS AS is a SIP based application server which provides IMS service logic.

[0033] 8) IMS ALG (IMS Application Layer Gateway) : The IMS ALG controls the IMS AGW to setup media security between the UE and the IMS core network.

[0034] 9) IMS AGW (IMS Access Media Gateway) : The IMS AGW provides media security between the UE and the IMS core network.

[0035] 10) MF (Media Function) : The MF provides the media resource management and forwarding of data channel media traffic. In supporting data channel service, the MF and MRF also provide the data channel media control functionality.

[0036] 11) DCSF (Data Channel Signaling Function) : The DCSF is the signaling control function that provides data channel control logic. The DCSF is not involved in SIP signaling.

[0037] 12) DC AS (Data Channel Application Server) : The DC AS provides application logic for a specific data channel application.

[0038] Comparing with audio / video service, data channel service is a special media service which sets up a special media channel for data application running on top of such special media channel. The data channel terms include bootstrap data channel and application data channel. A bootstrap data channel is a media channel which the bootstrap application runs on top of it. The bootstrap application is an entry for loading various data channel applications where each data channel application runs on top of a special application data channel established for a specific data channel application.

[0039] FIG. 2 describes the procedure flow to establish a bootstrap data channel in a person-to-person (P2P) use case. The MF anchors the bootstrap data channel, and the originating network is offering a bootstrap data channel to the remote peer as well for application download.

[0040] The steps in the call flow are as follows:

[0041] 1. UE#1 sends the SIP INVITE request with an initial SDP to the IMS AS, through P-CSCF and S-CSCF in the originating network. The initial SDP contains offers for the bootstrap data channel establishment request with bootstrap DC stream ID. In this example procedure, the SDP contains both bootstrap data channel offers for originating side and terminating side.

[0042] This SIP INVITE can also be a SIP re-INVITE performed after the initial IMS audio session is setup. The SIP re-INVITE can be initiated either from UE#1 or UE#2.

[0043] For the value range of DC Stream ID, 0～1000 is reserved to the bootstrap data channel. Particularly, some DC Stream ID values are reserved: 0 indicates the content source of local network initiated, 10 indicates the content source of local UE, 100 indicates the content source of remote network, 110 indicates the content source of remote UE.

[0044] 2. IMS AS validates user subscription data to determine whether the data channel call request should be notified to DCSF.

[0045] If the IMS AS determined, based on the user profile, that data channel call request needs to be notified to DCSF, the IMS AS selects a DCSF for this user based on local configuration or discovery and selection of a DCSF instance via NRF.

[0046] 3. IMS AS notifies the DCSF of the DC call event by sending Nimsas_SessionEventControl_Notify (SessionEstablishmentRequestEvent, Session ID, Calling ID, Called ID, Session Case, Event initiator, Media InfoList, DC Stream ID) request to the DCSF.

[0047] Calling ID is the public identity of the calling IMS subscriber. Called ID is the public identity of the called IMS Subscriber. Session case indicates if this is an originating or terminating IMS session. Event initiator indicates initiator of the event, i.e., 's erved IMS subscriber'vs 'remote IMS subscriber'. Media info list includes all the media component information. DC Stream ID identifies the requested DC stream, i.e., the bootstrap data channel in this procedure.

[0048] 4. After receiving the DC control request, the DCSF determines the policy about how to process the bootstrap data channel establishment request based on the related parameters in the Data Channel control request (e.g., CallingID, CalledID, DC Stream ID) and / or DCSF service specific policy.

[0049] 5. The DCSF reserves MDC1 media information for the bootstrap data channel. Two different MDC1 media information are reserved: the originating side MDC1 media information (targeting local UE, i.e., originating UE, for local side bootstrap data channel) and the terminating side MDC1 media information (targeting remote UE, i.e., terminating UE, for remote side bootstrap data channel) .

[0050] 6. DCSF invokes the Nimsas_MediaControl_MediaInstruction (Session ID, Media Instruction Set) operation based on its policies instructing the IMS AS how to set up bootstrap data channel with MF both for originating and terminating sides. The MediaInstructionSet provided by the DCSF, includes its MDC1 media endpoint addresses created in step 5, DC Stream ID, and the replacement HTTP URL representing the application list offered via the MDC1 interface.

[0051] In this scenario, the DCSF instructs the IMS AS to terminate bootstrap data channel establishment request on originating MF, and initiate remote bootstrap data channel establishment request (targeting remote UE) as well as forwarding remote bootstrap data channel establishment request of served user (targeting remote DCSF) towards terminating network.

[0052] 7. The IMS AS selects a MF based on local configuration or discovers and selects a MF supporting DC media function via NRF.

[0053] 8. IMS AS invokes Nmf_MRM_Create (List of Media Termination Descriptors) service operation to instruct MF to allocate required data channel media resources. IMS AS requests creation of two different Media Terminations, one representing the local bootstrap media to be terminated (i.e., to be offered to local / originating UE) and the other representing the remote bootstrap media to be offered to remote UE. Each Media Termination includes information required to allocate resources in both Mb and the MDC1 interfaces. The MF responds with the negotiated data channel media resource information to IMS AS. If MRF is used, IMS AS uses Mr' / Cr to the MRF to reserve data channel media resources.

[0054] The MF media resource allocation in step 8 could be done with one or multiple service invocations.

[0055] 9. IMS AS responds to the MediaInstruction request received in step 6. The response may include the atomic success result of operation and also includes negotiated data channel media resource information for MDC1.

[0056] 10. The DCSF stores the media resource information and responds to the Notify Request received in step 3.

[0057] 11-13. IMS AS sends the INVITE which includes the updated SDP offer adding media information of MF via the originating S-CSCF to remote network side and UE#2. In this scenario, the SDP offer for bootstrap data channel to UE#2 is included.

[0058] 14-18. UE#2 and / or terminating network returns an 18X response with the SDP answer to bootstrap data channel to originating network. According to the received SDP answer, IMS AS may instruct MF to update data channel media resource information for UE#2. In this document, “UE#2 and / or terminating network” is used to include i) UE#2, ii) the terminating network (regardless of the explicit indication of the involvement of UE#2) , or iii) both UE#2 and the terminating network.

[0059] 14. UE#2 and / or terminating network returns an 18X response (e.g., "183 Session Progressing" or "180 Ring" ) with the SDP answer to bootstrap data channel to originating network.

[0060] 15. UE#1 and / or originating network respond “PRACK. ” In this document, “UE#1 and / or originating network” is used to include i) UE#1, ii) the originating network (regardless of the explicit indication of the involvement of UE#1) , or iii) both UE#1 and the terminating network.

[0061] 16. UE#2 and / or terminating network sends “200 OK (PRACK) ” , to confirm success of SDP media negotiation.

[0062] According to the received SDP answer in step 14-16, IMS AS may instruct MF to update data channel media resource information for UE#2.

[0063] 17-18. “SIP UPDATE” may be invoked to negotiate new SDP media between originating UE and terminating UE.

[0064] 19-20: UE#2 and / or terminating network returns a 200 OK response to “SIP INVITE. ”

[0065] 21. The IMS AS notifies the successful session establishment event, Nimsas_SessionEventControl Notify (SessionEstablishmentSuccessEvent, Session ID, Media Info List) to DCSF.

[0066] 22. The DCSF responds to the Nimsas notification request.

[0067] 23. “200 OK” forwarded to UE#1 which indicates the bootstrap data channel has been established.

[0068] 24. The originating network P-CSCF executes QoS procedure for bootstrap data channel as specified in 3GPP TS 23.203 and 3GPP TS 23.503.

[0069] 25-28: The bootstrap data channels have been established between originating MF and UE#1 / UE#2. The UEs send application request messages to MF to request a data channel application or an application list if multiple DC applications are available, via the established bootstrap data channel with its data channel capabilities. The MF replaces the root URL with the replacement URL received in steps 8 and forwards the message to received media point of DCSF.

[0070] The DCSF provides the application list and proper data channel applications further to UE#1 and UE#2 based on their data channel capabilities and their choices through MF. In the DC application list, the DCSF may provide DC applications supported by both UEs, or only supported by the UE who sends the application request message. The details of how to provide the application list to the UE and how to use it by the UE is implementation specific.

[0071] The bootstrap data channels have also been established between terminating MF and UE#1 / UE#2. The data channel application is requested and downloaded to UE#1 and UE#2 from terminating DCSF.

[0072] Steps 20-24 may be executed after step 14, if the SDP answer in “200 OK” to the PRACK and UPDATE messages contain the information required to establish bootstrap data channels.

[0073] IMS-AGW needs to allow the establishment of bootstrap data channels based on the information in the “200 OK (PRACK) ” and “UPDATE” messages.

[0074] 29. Subsequent procedures continue.

[0075] Using the procedure as illustrated in FIG. 2, the originating UE initiates bootstrap data channel establishment with the terminating UE, and subsequently both the originating UE and terminating UE can download the DC applications from the established bootstrap data channel. Later, the originating UE can initiate application data channel establishment with the terminating UE, so as to run a specific data channel application between the two sides.

[0076] FIG. 3 describes the procedure flow to establish an application data channel in a person-to-person use case. In this scenario, the MF is not used to anchor the application data channel.

[0077] In the call flow as shown in FIG. 3, the UEs have already established an IMS audio session, and the originating UE is updating the IMS audio / video session to an IMS data channel session.

[0078] The steps in the call flow are as follows:

[0079] 0. IMS session and bootstrap data channel have been established. Selected data channel application (s) have been downloaded to UE#1 and possibly UE#2.

[0080] 1. UE#1 sends the SIP reINVITE request with an updated SDP to IMS AS, through originating network P-CSCF and S-CSCF. The updated SDP contains the bootstrap data channel information, as well as the requested application data channel and the associated DC application binding information, according to standards, e.g., 3GPP TS 26.114.

[0081] 2. The IMS AS validates user subscription data to determine whether the media change request event should be notified to the DCSF.

[0082] 3. The IMS AS notifies the DCSF, via Nimsas_SessionEventControl_Notify (MediaChangeRequestEvent, Session ID, Session Case, Event initiator, Media Info List) of the media change request event.

[0083] 4. After receiving the session event notification, the DCSF determines the policy about how to process the application data channel establishment request based on the related parameters (i.e., associated DC application binding information) in the notification and / or DCSF service specific policy.

[0084] 5. The DCSF determines that the added application data channel media descriptor of the SDP offer takes UE#2 as target endpoint and does not require anchoring on the local MF. If MF needs to anchor application data channel, DCSF would have used the Nimsas_MediaControl service operation to instruct IMS AS to allocate data channel media resources of the MF.

[0085] 6. DCSF responds to the notification received in step 3.

[0086] 7-8. IMS AS sends the re-INVITE to the originating S-CSCF and then to the terminating network side and UE#2.

[0087] 9-11. UE#2 and / or terminating network returns a 200 OK response with SDP answer for application data channel to originating network. Based on the received DC application binding information in the SDP offer of the re-INVITE, UE#2 may need to download the corresponding DC Application signalled in the SDP offer, if not done already and associate it with the requested application DC.

[0088] The UE at the terminating side is capable to determine if to use the DC application based on the received DC application binding information.

[0089] 12. IMS AS notifies the DCSF of the successful data channel modification.

[0090] 13. DCSF responds to the notification received in step 12.

[0091] 14-15. The IMS AS sends 200 OK response to the originating S-CSCF and P-CSCF.

[0092] 16. The originating network P-CSCF executes QoS procedure for application data channel media based on the SDP answer information from the 200 OK response.

[0093] 17. P-CSCF returns the 200 OK response to UE#1.

[0094] 18. UE#1 sends ACK to the terminating network.

[0095] 19. The application data channel between UE#1 and UE#2 is established. In this example, it is not anchored in MF / MRF.

[0096] As shown in the existing procedures as shown in FIGS. 2 and 3, there is no mechanism to establish early DC before the SIP session is confirmed (e.g., before “SIP 200 OK” ) . The bootstrap data channels are established after the SIP session is confirmed (e.g., the originating UE gets the “SIP 200 OK” ) . The application data channel is initiated by the UE after the bootstrap data channel is established and it gets the data channel application list through the bootstrap data channel.

[0097] To satisfy the new requirements, e.g., to play early media using data channel method, some implementations of the disclosed technology provide a method to allow the network to proactively establish early DC before a SIP session is confirmed (e.g., with “200 OK. ” ) .

[0098] Typical early media exchanges are used to support value-added IMS service to an SIP session. In a Person-2-Person (P2P) SIP session, early media exchange may happen between originating UE and terminating UE, e.g., to support CAT (Customized Alerting Tone) and CRS (Customized Ring Signaling) . In a Person-2-Application (P2A) SIP session, the value-added AS (VAS) may want to play early media to the originating UE. These early media services are possible to be implemented by early DC.

[0099] Implementation 1: Early DC Establishment Towards Terminating UE in P2P Procedure

[0100] In an SIP session, originating UE may want to play early media to the terminating UE (e.g., for CRS service) before the terminating UE accepts the SIP session (e.g., before the “200 OK” response is sent in response to the SIP INVITE) . In this case, early DC needs to be established towards the terminating UE.

[0101] FIG. 4 describes an example of an early DC establishment procedure towards the terminating UE based on some implementations of the disclosed technology. In this procedure, the originating UE and the terminating UE reside in different networks from each other, and the decision of early DC establishment towards originating UE is determined by the IMS AS and DCSF of the originating network.

[0102] The steps in the call flow are as follows:

[0103] 1. UE#1 sends the SIP INVITE request with an initial SDP to the IMS AS, similar to step 1 of FIG. 2 procedure. The description on step 1 of FIG. 2 can be applied.

[0104] In this step, the UE#1 may include an early DC support indication in the SIP INVITE request, to indicate its support of early DC establishment. In some implementations, an early DC support indication may be present in SIP header, e.g. "P-Early-Media" , "Supported" , "Required" or any other proper SIP header. Support of early DC might be carried in "P-Early-Media" i.e. with additional attribute to "P-Early-Media" (e.g. "P-Early-Media: dc" ) . The SIP header "Supported" may be also used by the UE#1 to indicate its special capability (e.g. "Supported: early-dc" ) .

[0105] 2. IMS AS validates user subscription data to determine whether the data channel call request needs to be notified to DCSF, which is similar to step 2 in FIG. 2. The description on step 2 of FIG. 2 can be applied.

[0106] In this step, the user subscription data may include early DC service profile, which indicates whether the UE has subscribed early DC related services. The early DC service profile contains at least one of the following: (a) a general early DC subscribed indication that is used to indicate early DC related service is subscribed; (b) early DC for CAT service is subscribed; (c) early DC for CRS service is subscribed.

[0107] 3. IMS AS notifies the DCSF of the DC call event by sending Nimsas_SessionEventControl_Notify (SessionEstablishmentRequestEvent, Session ID, Calling ID, Called ID, Session Case, Event initiator, Media InfoList, DC Stream ID) request to the DCSF, which is similar to step 3 of FIG. 2. The description on step 3 of FIG. 2 can be applied.

[0108] In this step, the IMS AS may include "early DC required" indication in the request message, to indicate that the early DC establishment is required. The IMS AS detects the "early DC required" indication based on at least one of the following items: early DC support indication received from UE, early DC subscription information retrieved from user subscription data.

[0109] 4. After receiving the DC control request from IMS AS, the DCSF determines the DC control policy, based on the related parameters in the data channel control request (e.g., CallingID, CalledID, DC Stream ID) and / or DCSF service specific policy. The DCSF determines that the bootstrap data channel needs to be established, based on the media info list and DC Stream ID in the request message from the IMS AS.

[0110] In this step, the DCSF determines that DC control policy for an early DC is also required, based on the "early DC required" indication in the request message from the IMS AS.

[0111] 5. The DCSF reserves DC media information for bootstrap data channel, e.g., both for originating side MDC1 media information (targeting local UE, i.e., originating UE, for local side bootstrap data channel) and terminating side MDC1 media information (targeting remote UE, i.e., terminating UE, for remote side bootstrap data channel) .

[0112] In this step, the DCSF reserves DC media information for early DC. As the early DC is towards the terminating UE, the DC media information for early DC includes terminating side MDC1 media information.

[0113] 6. DCSF invokes the Nimsas_MediaControl_MediaInstruction (Session ID, Media Instruction Set) operation based on its DC control policies. The Media Instruction Set contains instructions to the IMS AS about how to set up bootstrap data channel with MF for both originating and terminating sides.

[0114] In this step, the Media Instruction Set contains instructions to the IMS AS about how to set up the early DC with MF for the terminating side. For example, the instructions included in the Media Instruction Set is used to instruct the MF to set up the early DC corresponding to the reserved DC media information.

[0115] 7. The IMS AS selects a MF based on local configuration or discovers and selects a MF supporting DC media function via NRF.

[0116] 8. IMS AS invokes Nmf_MRM_Create (List of Media Termination Descriptors) service operation to instruct MF to allocate required data channel media resources. The MF responds with the negotiated data channel media resource information to IMS AS. If MRF is used, IMS AS uses Mr' / Cr to the MRF to reserve data channel media resources.

[0117] For bootstrap data channel, IMS AS requests to create two different Media Terminations for bootstrap data channel, one representing the local bootstrap media termination to be offered to originating UE and the other representing the remote bootstrap media to be offered to remote UE. Each Media Termination includes information required to allocate resources in both Mb and the MDC1 interfaces.

[0118] In this step, the IMS AS also requests to create one Media Termination for the early DC, which represents the remote media termination to be offered to the terminating UE.

[0119] 9. IMS AS responds to the MediaInstruction request received in step 6. For example, the IMS AS sends the response, e.g., Nimsas_MediaControl_MediaInstruction response, to DCSF. The response may include the atomic success result of operation and also includes negotiated data channel media resource information for MDC1.

[0120] 10. The DCSF stores the media resource information and responds to the Notify Request received in step 3. For example, the DCSF sends, to the IMS AS, the response, e.g., Nimsas_SessionEvent Control_Notify_response.

[0121] 11-12. IMS AS sends the INVITE which includes the updated SDP offer via the originating S-CSCF to remote network side and UE#2. In the INVITE message, the updated SDP offer adding media information of MF for bootstrap data channel is included.

[0122] 13. The SIP INVITE reaches terminating network and terminating UE (i.e., UE#2) . The terminating network and the terminating UE negotiate the SDP answer to the INVITE message.

[0123] 14. UE#2 and the terminating network return an 18X response (e.g., "183 Session Progressing" or "180 Ring" ) with the SDP answer to bootstrap data channel.

[0124] 15. UE#1 and the originating network respond “PRACK. ”

[0125] 16. UE#2 and the terminating network send “200 OK” to “PRACK, ” to confirm success of SDP media negotiation.

[0126] Upon receiving the “200 OK (PRACK) , ” according to the received SDP answer in previous step, IMS AS may instruct MF to update data channel media resource information for UE#2.

[0127] 17-18. IMS AS sends SIP UPDATE to UE#2, with SDP offer for early DC, so as to negotiate the SDP for early DC establishment between originating network and UE#2. UE#2 sends 200 OK with SDP answer for early DC to confirm the acceptance of early DC establishment. The 200 OK (UPDATE) sent in Step 18 is different from 200 OK (PRACK) in Step 16 as in step 16 the 200 OK (PRACK) is to confirm the SDP negotiation for bootstrap DC while in step 18 the 200 OK (UPDATE) is to confirm the SDP negotiation of early DC.

[0128] 19-20: IMS AS may send notification to DCSF, to inform the negotiation result of early DC.

[0129] 21. UE#2 sets up early DC towards originating MF, based on the information in SDP offer for early DC in step 12.

[0130] 22. UE#2 downloads a data channel application from the early DC, and runs the downloaded application.

[0131] 23-24: UE#2 and / or terminating network returns a 200 OK response.

[0132] 25. The IMS AS notifies the successful session establishment event, Nimsas_SessionEventControl Notify (SessionEstablishmentSuccessEvent, Session ID, Media Info List) to DCSF.

[0133] 26. The DCSF responds to the Nimsas notification request.

[0134] 27. Once the IMS AS receives “200 OK” in step 19-20 which means the SIP session is successfully negotiated, the IMS AS determines the early DC needs to be released.

[0135] 28. “200 OK” forwarded to UE#1 which indicates the bootstrap data channel has been established.

[0136] 29. Subsequent steps for bootstrap data channel establishment, e.g., bootstrap data channel establishment between the originating UE and the MF, and the bootstrap data channel establishment between the terminating UE and the MF. Once the bootstrap data channel is established, the originating UE / the terminating UE downloads data channel application list through the bootstrap data channel and may download one specific data channel application to run the downloaded application.

[0137] In the above procedure, the IMS AS first triggers the DCSF and the MF to reserve media resources for the early DC. Later, the IMS AS uses “SIP UPDATE” to request the terminating UE to establish the early DC with MF.

[0138] It is to be noted that this early DC establishment towards terminating UE in P2P procedure as described in relation to FIG. 4 can be applied to the case when the originating UE and the terminating UE reside in the same network.

[0139] Implementation 2: Early DC Establishment Towards Originating UE in P2A Procedure

[0140] In a P2A SIP session, value-added AS may want to play early media to the originating UE before it accepts the SIP session (e.g., before the final “200 OK” response is sent in response to the SIP INVITE) . In this case, early DC needs to be established towards the originating UE.

[0141] FIG. 5 describes an example of an early DC establishment procedure towards an originating UE in P2A procedure based on some implementations of the disclosed technology. In this procedure, the P2A procedure occurs in the same network, and the decision of early DC establishment towards originating UE is determined by the IMS AS and DCSF.

[0142] The steps in the call flow are as follows:

[0143] 1. UE#1 sends the SIP INVITE request with an initial SDP to the IMS AS, similar to step 1 in FIG. 4. The description on step 1 of FIG. 4 can be applied.

[0144] In this step, the UE#1 may include an early DC support indication in the SIP INVITE request, to indicate its support of early DC establishment. In some implementations, an early DC support indication may be present in the SIP header e.g. "P-Early-Media"" , "supported" , "required" or any other proper SIP header.

[0145] 2. IMS AS validates user subscription data to determine whether the data channel call request should be notified to DCSF, which is similar to step 2 in FIG. 4.

[0146] In this step, the IMS AS retrieves early DC subscription information from user subscription data. In some implementations, the IMS AS may acknowledge the service requirement for early DC, e.g., based on local policy or other configurations. In this scenario, the service requirement for early DC indicates whether a SIP session towards the target VAS requires early DC.

[0147] 3. IMS AS notifies the DCSF of the DC call event by sending a request message (e.g., Nimsas_SessionEventControl_Notify request) to the DCSF, which is similar to step 3 in FIG. 4.

[0148] In this step, the IMS AS may include the "early DC required" indication in the request message. The IMS AS determines the "early DC required" indication, which is included in the request message, based on at least one of the following items: the early DC support indication received from UE (e.g., from originating UE in this scenario) , the early DC subscription information retrieved from user subscription data, or the service requirement for early DC.

[0149] 4-10. Similar to steps 4-11 in FIG. 4. The description on steps 4-11 in FIG. 4 can be applied.

[0150] 11. IMS AS modifies the SDP offer for bootstrap DC, to adapt the media resource reservation for bootstrap DC.

[0151] 12-16. Similar to steps 12-16 in FIG. 4. The description on steps 12-16 in FIG. 4 can be applied. For example, IMS AS forwards SIP INVITE to VAS, with a modified SDP offer for bootstrap DC, to negotiate SDP for bootstrap DC with the terminating side.

[0152] In step 12-16, only bootstrap DC is negotiated but no early DC to be negotiated.

[0153] In this scenario, the VAS acts as an SIP AS thus the SIP INVITE is forwarded to the VAS.

[0154] 17-18. IMS AS sends “UPDATE” to UE#1, with SDP offer for the early DC. UE#1 sends “200 OK” with SDP answer for early DC to confirm the acceptance of early DC establishment.

[0155] 19-20: IMS AS may send notification to DCSF, to inform the negotiation result of the early DC.

[0156] 21. UE#1 sets up early DC towards the originating MF, based on the information in SDP offer for early DC in step 17-18.

[0157] 22. UE#1 downloads data channel application from early DC, and runs the downloaded application.

[0158] 23-29. Similar to steps 23-29 in FIG. 4. The description on steps 23-29 in FIG. 4 can be applied.

[0159] In the above procedure, the IMS AS first triggers the DCSF and MF to reserve media resource for early DC. Later, the IMS AS uses SIP UPDATE to request the originating UE to establish the early DC with MF.

[0160] Implementation 3: Early DC Establishment Towards Originating UE in P2P Procedure

[0161] In an SIP session, the terminating UE may want to play early media to the originating UE (e.g., for CAT service) before the terminating UE accepts the SIP session (e.g., before the final “200 OK” response is sent in response to the SIP INVITE) . In this case, early DC needs to be established towards the originating UE.

[0162] FIG. 6 describes an example of an early DC establishment procedure towards the originating UE in P2P procedure based on some implementations of the disclosed technology. In this procedure, the originating UE and terminating UE reside in different network, and the decision of early DC establishment towards originating UE is determined by the IMS AS and DCSF of the terminating network.

[0163] The steps in the call flow are as follows:

[0164] 1-16. Similar to steps 1-16 in FIG. 4. The description in steps 1-16 in FIG. 4 can be applied.

[0165] 17. The terminating network may want to play early media to the originating UE. To support this, the terminating network decides to reserve media resource for the early DC (e.g., at terminating MF) .

[0166] 18. UE#2 sends SIP “UPDATE” to UE#1 with SDP offer for early DC. The SIP “UPDATE” message routes via IMS AS in terminating network and IMS AS in originating network.

[0167] When the IMS AS in terminating network receives SIP UPDATE with SDP offer for early DC, it requests the DCSF in terminating network to reserve media resource for early DC at the MF in terminating network, and updates the SDP offer for early DC to adapt the media resource at terminating side.

[0168] When the IMS AS in originating network receives SIP UPDATE with SDP offer for early DC, it requests the DCSF in originating network to reserve media resource for early DC at the MF in originating network, and updates the SDP offer for early DC to reflect to adapt the media resource at originating side.

[0169] 19. UE#1 sends “200 OK” with SDP answer for early DC to confirm the acceptance of early DC establishment.

[0170] 20. IMS AS in the terminating network may notify DCSF in the terminating network the negotiation of the early DC.

[0171] 21. UE#1 sets up the early DC towards the terminating MF, based on the information in SDP offer for early DC in previous steps.

[0172] 22. UE#1 downloads data channel application from the early DC, and runs the downloaded application.

[0173] 23-29: Similar to steps 23-29 in FIG. 4. The description on steps 23-29 in FIG. 4 can be applied.

[0174] FIG. 7 describes example operations of the terminating network for determining an early DC and reserving a media resource for early DC based on some implementations of the disclosed technology. The operations as shown in FIG. 7 may correspond to steps 12-20 of FIG. 6.

[0175] The steps in the call flow are as follows:

[0176] 1. The terminating S-CSCF receives SIP INVITE request from originating network, and forwards the request to the terminating IMS AS.

[0177] 2-10. Similar to the handling of early DC in the originating network, which are illustrated in step 2-10 of FIG. 6. In the terminating network, the IMS AS may determine that early DC is required for the SIP session, e.g., to support CAT service for the originating UE. The IMS AS interacts with DCSF and MF to request the reservation of media resource for the early DC.

[0178] 11-16. Corresponding to step 11-16 of FIG. 6. The descriptions on steps 11-16 of FIG. 6 can be applied.

[0179] 17. The terminating UE determines that early DC is required.

[0180] 18-19. Corresponding to step 18-19 in FIG. 6. UE#2 sends SIP UPDATE message to negotiate SDP for the early DC. The SIP UPDATE routes via IMS AS in the terminating network and the IMS AS updates the SDP offer for the early DC to adapt the media resource reserved (by terminating MF) for the early DC.

[0181] 20. The terminating IMS AS may notify the DCSF the negotiation result of the early DC.

[0182] In the above procedure of FIGS. 6 and 7, the originating IMS AS first triggers the originating DCSF and originating MF to reserves the media resource for the early DC. Later, the terminating UE uses SIP UPDATE to negotiate SDP for the early DC with the originating UE, and the originating IMS AS updates the SDP for early DC to adapt the reserved media resource for early DC.

[0183] Through the above procedures, it provides the network a proper way to trigger early DC establishment, so that the early media can be delivered to the originating / terminating UE or exchanged between the originating UE (or the originating network) and the terminating UE (or the terminating network) .

[0184] FIG. 8 is a block diagram representation of a portion of an apparatus, in accordance with some embodiments of the presently disclosed technology. An apparatus 810 such as a network device or a base station or a wireless device (or UE) , can include processor electronics 820 such as a microprocessor that implements one or more of the techniques presented in this document. The apparatus 810 can include transceiver electronics 830 to send and / or receive wireless signals over one or more communication interfaces such as antenna (s) 840. The apparatus 810 can include other communication interfaces for transmitting and receiving data. Apparatus 810 can include one or more memories (not explicitly shown) configured to store information such as data and / or instructions. In some implementations, the processor electronics 820 can include at least a portion of the transceiver electronics 830. In some embodiments, at least some of the disclosed techniques, modules or functions are implemented using the apparatus 810.

[0185] Some preferred embodiments may include the following solutions.

[0186] 1. A method for wireless communications (e.g., method 900 as shown in FIG. 9) , comprising: receiving 910, by a user device in a first network configured to be in communication with a second network, a session description protocol (SDP) offer requesting an early data channel (DC) during a session initiation protocol (SIP) session establishment procedure; and establishing 920 the early DC between the user device and the second network before the SIP session is successfully established.

[0187] Corresponding to the method 900 implemented by the user device, a method is implemented by a network node in which the network node transmits to the user device in the first network configured to be in communication with the second network, a session description protocol (SDP) offer requesting an early data channel (DC) during a session initiation protocol (SIP) session establishment procedure; thereby causing establishment of the early DC between the user device and the second network before the SIP session is successfully established. Other features of these methods are further disclosed in the various solutions listed herein.

[0188] 2. The method of solution 1, wherein an SIP message including an indication indicating a support for the early DC is communicated in the second network before the receiving of the SDP offer.

[0189] 3. The method of solution 2, wherein the indication is included in a header of the SIP message.

[0190] 4. The method of solution 1, wherein the SDP offer is included in a SIP update message that is invoked to negotiate SDP media between the user device in the first network and the second network.

[0191] 5. The method of solution 1, wherein the early DC is established through a media endpoint provided in the SDP offer before a confirmation message confirming the SIP session is exchanged.

[0192] 6. A method for wireless communications (e.g., method 1000 as shown in FIG. 10) , comprising: determining 1010, by an IP multimedia subsystem (IMS) application server in a network, that an early data channel (DC) is required for a session initiation protocol (SIP) session, the early DC refers to a data channel established before the SIP session is successfully established; sending 1020, to a data channel signaling function in the network, a first message that requests to reserve media resource information for the early DC; and sending 1030, to a call session control function in the network, a session description protocol (SDP) offer requesting the early DC.

[0193] Corresponding to the method 1000 implemented by the IS application server in the network, a method is implemented by the data channel signaling function in the network to receive a first message that requests to reserve media resource information for the early DC. Corresponding to the method 1000 implemented by the IS application server in the network, a method is implemented by a call session control function in the network to receive a session description protocol (SDP) offer requesting the early DC.

[0194] 7. The method of solution 6, further comprising: receiving, from the data channel signaling function, a media resource instruction for the early DC; and sending, to a media function in the network, a second message that requests to reserve a media resource for the early DC.

[0195] 8. The method of solution 6, further comprising: receiving, from a user device in the network, a SIP message including an indication indicating a support for the early DC, wherein the determining that the early DC is required for the SIP session is made based on the indication.

[0196] 9. The method of solution 6, further comprising: validating user subscription data that includes an early DC service profile that indicates whether a user device has subscribed early DC related services.

[0197] 10. The method of solution 6, further comprising: retrieving an early DC subscription information from user subscription data, or acknowledging a service requirement for the early DC, wherein the determining that the early DC is required for the SIP session is made based on the early DC subscription information or the service requirement for early DC.

[0198] 11. The method of solution 6, wherein the first message includes an IMS session event notification including an early DC required indication indicating that the early DC establishment is required.

[0199] 12. The method of solution 6, wherein the SDP offer for the early DC is sent to a user device in another network.

[0200] 13. A method of wireless communications (e.g., method 1100 as shown in FIG. 11) , comprising: receiving 1110, by a data channel signaling function and from a multimedia subsystem (IMS) application server, a request to reserve media resource information for an early data channel (DC) that refers to a data channel established before a session initiation protocol (SIP) session is successfully established; reserving media resource information for the early DC based on the request; and sending 1120, to the IMS application server, a media resource instruction for the early DC that instructs the IMS application server to set up the early DC based on the media resource information.

[0201] Corresponding to the method 1100 implemented by the data channel signaling function, a method is implemented by a IMS application server to a request to reserve media resource information for an early data channel (DC) that refers to a data channel established before a session initiation protocol (SIP) session is successfully established, and receive the media resource instruction for the early DC that instructs the IMS application server to set up the early DC based on the media resource information. Other features of these methods are further disclosed in the various solutions listed herein.

[0202] 14. The method of solution 13, wherein the request includes an IMS session event notification including an early DC required indication indicating that the early DC establishment is required.

[0203] 15. A method for wireless communication, comprising: transmitting, by an originating user device configured to be in communication with a terminating user device, a session initiation protocol (SIP) message including an indication indicating a support for an early data channel (DC) , the early DC refers to a data channel established before the SIP session is successfully established.

[0204] 16. The method of solution 15, wherein the indication is included in a header of the SIP.

[0205] 17. A wireless communication apparatus comprising a processor configured to implement a method recited in any of above solutions.

[0206] 18. A computer storage medium having code stored thereupon, the code, upon execution by a processor, causing the processor to implement a method recited in any of above solutions.

[0207] The disclosed and other embodiments, modules and the functional operations described in this document can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in combinations of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more them. The term "data processing apparatus" encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus.

[0208] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document) , in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code) . A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0209] The processes and logic flows described in this document can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit) .

[0210] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0211] While this document contains many specifics, these should not be construed as limitations on the scope of an invention that is claimed or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination. Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results.

[0212] Only a few examples and implementations are disclosed. Variations, modifications, and enhancements to the described examples and implementations and other implementations can be made based on what is disclosed.

Claims

1.A method for wireless communications, comprising:receiving, by a user device in a first network configured to be in communication with a second network, a session description protocol (SDP) offer requesting an early data channel (DC) during a session initiation protocol (SIP) session establishment procedure; andestablishing the early DC between the user device and the second network before the SIP session is successfully established.2.The method of claim 1, wherein an SIP message including an indication indicating a support for the early DC is communicated in the second network before the receiving of the SDP offer.3.The method of claim 2, wherein the indication is included in a header of the SIP message.4.The method of claim 1, wherein the SDP offer is included in a SIP update message that is invoked to negotiate SDP media between the user device in the first network and the second network.5.The method of claim 1, wherein the early DC is established through a media endpoint provided in the SDP offer before a confirmation message confirming the SIP session is exchanged.6.A method for wireless communications, comprising:determining, by an IP multimedia subsystem (IMS) application server in a network, that an early data channel (DC) is required for a session initiation protocol (SIP) session, wherein the early DC refers to a data channel established before the SIP session is successfully established;sending, to a data channel signaling function in the network, a first message that requests to reserve media resource information for the early DC; andsending, to a call session control function in the network, a session description protocol (SDP) offer requesting the early DC.7.The method of claim 6, further comprising:receiving, from the data channel signaling function, a media resource instruction for the early DC; andsending, to a media function in the network, a second message that requests to reserve a media resource for the early DC.8.The method of claim 6, further comprising:receiving, from a user device in the network, a SIP message including an indication indicating a support for the early DC,wherein the determining that the early DC is required for the SIP session is made based on the indication.9.The method of claim 6, further comprising:validating user subscription data that includes an early DC service profile that indicates whether a user device has subscribed early DC related services.10.The method of claim 6, further comprising:retrieving an early DC subscription information from user subscription data, or acknowledging a service requirement for the early DC,wherein the determining that the early DC is required for the SIP session is made based on the early DC subscription information or the service requirement for early DC.11.The method of claim 6, wherein the first message includes an IMS session event notification including an early DC required indication indicating that the early DC establishment is required.12.The method of claim 6, wherein the SDP offer for the early DC is sent to a user device in another network.13.A method of wireless communications, comprising:receiving, by a data channel signaling function and from a multimedia subsystem (IMS) application server, a request to reserve media resource information for an early data channel (DC) that refers to a data channel established before a session initiation protocol (SIP) session is successfully established;reserving media resource information for the early DC based on the request; andsending, to the IMS application server, a media resource instruction for the early DC that instructs the IMS application server to set up the early DC based on the media resource information.14.The method of claim 13, wherein the request includes an IMS session event notification including an early DC required indication indicating that the early DC establishment is required.15.A wireless communication apparatus comprising at least one processor configured to cause the wireless communication apparatus to implement a method recited in any of above claims.16.A computer storage medium having code stored thereupon, the code, upon execution by a processor, causing the processor to implement a method recited in any of above claims.

Images