Early data channel establishment schemes

Abstract

A method of wireless communication is provided. The method comprises: receiving, by a first user device in a first network configured to be in communication with a second network, early data channel (DC) information during a session initiation protocol (SIP) establishment procedure, the early DC information indicating that the early DC needs to be established; and establishing, based on the early DC information, the early DC between the first 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. A 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 first user device in a first network configured to be in communication with a second network, early data channel (DC) information during a session initiation protocol (SIP) establishment procedure, the early DC information indicating that the early DC needs to be established; and establishing, based on the early DC information, the early DC between the first 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 or a media function in the network, a first message that requests to reserve media resource information for the early DC; and sending, to a cell session control function in the network, a second message including an early DC information that is forwarded from the cell session control function to a user device in another network.

[0006] In another example aspect, a method of wireless communication is disclosed. The method comprises 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; determining early DC information; 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, the media resource instruction including the early DC 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 communications 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 services.

[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 determining an early DC and reserving a media resource for the early DC based on some implementations of the disclosed technology.

[0017] FIG. 8 shows an example of a hop-by-hop early DC based on some implementations of the disclosed technology.

[0018] FIG. 9 shows an example wireless communications network based on some implementations of the disclosed technology.

[0019] FIGS. 10-12 are example flowcharts of a wireless communication method based on some implementations of the disclosed technology.DETAILED DESCRIPTION

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

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] 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.

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

[0027] 1) UE (User Equipment)

[0028] 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) .

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

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

[0031] 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.

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

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

[0034] 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.

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

[0036] 10) MF / MRF (Media Function / Media Resource Function) : The MF and MRF provide 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.

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

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

[0039] 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.

[0040] 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.

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

[0042] 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.

[0043] 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.

[0044] 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.

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

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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) .

[0051] 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.

[0052] 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.

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

[0054] 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.

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

[0056] 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.

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

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

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

[0063] 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.

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

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

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

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

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

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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.

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

[0075] 29. Subsequent procedures continue.

[0076] 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.

[0077] 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.

[0078] 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.

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

[0080] 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.

[0081] 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.

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

[0083] 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.

[0084] 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.

[0085] 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.

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

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

[0088] 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.

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

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

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

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

[0093] 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.

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

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

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

[0097] 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.

[0098] 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. ” ) .

[0099] 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.

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

[0101] In an SIP session, the originating network 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.

[0102] 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.

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

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

[0105] 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. 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" ) .

[0106] 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.

[0107] 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 Customized Alerting Tone (CAT) service is subscribed; or (c) early DC for Customized Ring Signaling (CRS) service is subscribed. In some examples, the terminating UE / NW wants to play customized alerting tone (that is subscribed by terminating UE) to originating UE when the originating UE calls terminating UE. In some examples, the originating UE / NW wants to play customized ring audio / video (that is subscribed by originating UE) to terminating UE when the originating UE calls terminating UE.

[0108] 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.

[0109] 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 service profile retrieved from user subscription data.

[0110] 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.

[0111] 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.

[0112] 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) .

[0113] 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.

[0114] In some implementations, in addition to reserving of the DC media information for early DC, the DCSF determines the early DC information used in SIP signalling based on the user subscription profile of the originating UE and the DC application configurations. The early DC information may include at least one of the following: "early DC required" indication, DC stream ID for early DC, DC application ID for the early DC, or DC application URI for early DC.

[0115] 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.

[0116] 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 with MF corresponding to the reserved DC media information.

[0117] In some implementations, in this step, the DCSF includes, in the Media Instruction Set, the early DC information that is determined by the DCSF in step 5.

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

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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_SessionEventControl_Notify_response.

[0124] 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.

[0125] In some implementations, in this step, the IMS AS also includes the early DC information in the SIP INVITE request sent to UE#2, which is determined by the DCSF in step 5. The early DC information allows to inform UE#2 (i.e. the terminating UE) that early DC is required to be established and it also informs UE#2 how to find the DC application for early DC. In the implementation, the early DC information included in the INVITE is sent by the IMS AS to the originating S-CSCF and then forwarded from the originating S-CSCF to the terminating network and / or UE#2.

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

[0127] In some implementations, in this step, UE#2 and / or the terminating network may determine if the early DC establishment request is acceptable or not, when receiving the early DC information in the SIP INVITE request.

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

[0129] In some implementations, in this step, UE#2 and / or the terminating network may include an early DC acceptance indication, to indicate that early DC establishment request is accepted by UE#2 (i.e. terminating UE) .

[0130] 14B. On receiving 18x response from terminating network, the originating IMS AS forwards 18x response with the SDP offer for bootstrap DC to UE#1, but removes the early DC information and the early DC acceptance indication if any.

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

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

[0133] 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.

[0134] 17-18. The SIP UPDATE may be used between originating network (or originating UE) and terminating UE to negotiate new media. In one example, the originating network may want to negotiate the SDP for the early DC with the terminating UE from the beginning.

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

[0136] 21a. UE#2 sets up the bootstrap DC towards the originating MF based on the information in SDP offer for bootstrap DC in step 12.

[0137] 21b. UE#2 sends request to the originating MF to download the DC application list. Since the originating MF itself does not have the knowledge of the DC application list, the originating MF requests the originating DCSF for the DC application list. After retrieving the DC application list from the originating DCSF, the originating MF forwards the DC application list to UE#2. The DC application list includes one DC application corresponding to the early DC information.

[0138] 22a. UE#2 sets up the early DC towards the originating MF based on the early DC information in step 12, and the information of retrieved DC application list.

[0139] 22b. UE#2 downloads the early DC application from the originating MF (the request is actually redirected to the originating DCSF) and runs the early DC application to receive the early media from the originating network (e.g. so that to display early media to the terminating user) .

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

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

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

[0143] 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.

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

[0145] In this scenario, it is the originating network which wants to play early media to terminating UE, thus early DC is established between the originating MF and the terminating UE. The originating IMS triggers the originating DCSF and the originating MF to reserve the media resource for the early DC, and provide the early DC information in SIP INVITE to the terminating UE. The terminating UE thus knows that the early DC is required, sets up the early DC with the originating MF and download the indicated early DC application from the originating network to run the application.

[0146] 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.

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

[0148] 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 SIP 200 OK response to the SIP INVITE) . In this case, early DC needs to be established towards the originating UE.

[0149] FIG. 5 describes the early DC establishment procedure towards originating UE in P2A procedure. In this procedure, the P2A procedure happens in the same network, and the decision of early DC establishment towards originating UE is determined by the IMS AS and DCSF.

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

[0151] 1-16. Similar to steps 1-16 in FIG. 4, with the following changes:

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

[0153] In step 3, the IMS AS determines the "early DC required" indication, based on at least one of the following: early DC support indication received from UE (e.g., from originating UE in this scenario) , early DC service profile retrieved from user subscription data, or service requirement for the early DC (related to the target VAS) .

[0154] In step 11-12, the IMS AS forwards SIP INVITE to VAS. As in this scenario the VAS acts as an SIP AS, VAS needs to be involved in the SDP negotiation. The IMS AS determines that the early DC towards the originating UE is required, and thus includes the early DC information in the SIP INVITE message.

[0155] In step 14A, the 18x Response includes the SDP answer to the bootstrap DC determined by the VAS. The 18x Response also includes the early DC information. In some implementations, the 18x Response may also include an early DC acceptance indication to indicate that VAS has accepted the early DC establishment request.

[0156] In step 14B, when sending 18x Response to the originating UE, the IMS AS includes, in the 18x Response, the SDP answer to bootstrap DC and early DC information. The IMS AS removes the early DC acceptance indication received in step 14A.

[0157] 17-18. IMS AS may send SIP UPDATE to UE#1 to negotiate new media. One example is, the IMS AS may want to negotiate the SDP for the early DC with the originating UE from the beginning.

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

[0159] 21a. UE#1 sets up the bootstrap DC towards the originating MF, based on the information in SDP answer for bootstrap DC in step 14A / 14B.

[0160] 21b. UE#1 sends request to originating MF to download the DC application list. MF further requests DC application list from DCSF.

[0161] 22a. UE#1 sets up early DC towards originating MF, based on the early DC information in step 14A / 14B, and the information of retrieved DC application list.

[0162] 22b. UE#1 downloads early DC application from originating MF (the request is actually redirected to originating DCSF) , and runs it to receiving early media from originating network (e.g., so that to display early media to originating user) .

[0163] 23-29. Similar steps to steps 23-29 in FIG. 4.

[0164] In the above procedure as shown in FIG. 5, it is the originating network which wants to play the early media to the originating UE, and thus the early DC is established between the originating MF and the originating UE. The originating IMS triggers the originating DCSF and the originating MF to reserve the media resource for the early DC, and provides the early DC information in SIP INVITE to the originating UE. The originating UE knows that the early DC is required. The originating UE sets up early DC and download the indicated early DC application from the originating network to run the indicated early DC application.

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

[0166] In an SIP session, the terminating network 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.

[0167] 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 networks, and the decision of early DC establishment towards originating UE is coordinately determined by the IMS AS and / or DCSF of the terminating network.

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

[0169] 1-16. Similar to steps 1-16 in FIG. 4 with the following changes:

[0170] In step 14A, the 18x Response includes the SDP answer to bootstrap DC determined by the terminating network and / or UE#2. The 18x Response also includes the early DC information. In addition, the 18x Response may also carry an early DC acceptance indication to indicate that the terminating network and / or UE#2 have accepted the early DC establishment request.

[0171] In step 14B, when sending 18x Response to the originating UE, the IMS AS removes the early DC acceptance indication received in step 14A.

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

[0173] When the terminating IMS AS receives SIP UPDATE with the early DC information, it requests the terminating DCSF to reserve the media resource for the early DC at the terminating MF, and generates the SDP offer for the early DC (to reflect the media resource for the early DC at the terminating side) .

[0174] 18A. UE#2 and / or the terminating network send the SIP UPDATE to the originating network with the SDP offer for early DC.

[0175] The SIP UPDATE message routes via the terminating IMS AS and towards the originating IMS AS. In this scenario, the negotiation of SDP for the early DC happens only between the originating IMS AS and the terminating network (i.e., terminating IMS AS) without involving the originating UE. Thus, the IMS AS does not forward the SIP UPDATE to the originating UE.

[0176] 18B. The originating IMS AS instructs the originating MF to bridge the media channel towards the originating UE with the media channel towards the terminating network.

[0177] In this scenario, hop-by-hop media channels are to be allocated, which include: (a) media channel between originating UE and originating MF, (b) media channel between originating MF and terminating MF.

[0178] To support the early DC establishment between the originating UE (or the originating network) and the terminating network (or the terminating UE) while allowing the early DC establishment to be under the control of the originating network, a media anchor in originating network needs to be added in the path. To do this, the originating IMS AS requests the originating MF to allocate media endpoints so as to bridge the above media channels, i.e., bridge hop-by-hop media channel (a) and (b) .

[0179] 18C. The originating IMS AS sends “200 OK” with SDP answer to early DC to terminating network.

[0180] 19. The IMS AS may send SIP UPDATE to UE#1 to update the SDP offer for bootstrap DC, if there is a change to the media endpoint of the data channel within the SDP. UE#1 acknowledges the updated SDP offer for bootstrap DC with “200 OK” response to SIP UPDATE.

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

[0182] 21a. UE#1 sets up the bootstrap DC towards the originating MF, based on the information in the SDP offer for bootstrap DC in step 12.

[0183] 21b. UE#1 downloads the DC application list from MF, MF requests DC application list from DCSF.

[0184] 22a. UE#1 sets up the early DC towards the originating MF, based on the information in the SDP offer for bootstrap DC and the early DC information in step 12.

[0185] 22b. UE#1 downloads the early DC application from the originating MF, and runs it once retrieving the early DC application.

[0186] In this step, the originating MF acts as a proxy to download the early DC application from the terminating network. The originating MF replaces the URL of the GET request for downloading early DC application, forwards the request to terminating network, and returns the retrieved early DC application to UE#1.

[0187] 23-29: Similar to steps 23-29 in FIG. 4.

[0188] 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.

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

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

[0191] 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.

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

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

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

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

[0196] FIG. 8 describes an example of a hop-by-hop early DC among an originating UE, an originating MF, and a terminating MF based on some implementations of the disclosed technology.

[0197] In FIG. 8, the logical early DC between the originating UE and the terminating MF contains 2 hop-by-hop physical media channels, which include (a) the media channel between the originating UE and the originating MF, and (b) the media channel between the originating MF and the terminating UE. The originating IMS AS instructs the originating MF to bridge above 2 media channels together to create a logical early DC. The originating MF acts as the media proxy to relay the early DC between the originating UE and the terminating MF.

[0198] In the above procedure of FIGS. 6-8, it is the terminating network which wants to play early media to the originating UE, thus the early DC is actually established between the originating UE and the terminating network. However, using hop-by-hop early DC, the originating UE is only aware of the first hop of the early DC. With this method, the originating network has provisioned the bootstrap DC and the early DC information can be used to indicate to originating UE that the early DC is required (by the originating network) .

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

[0200] FIG. 9 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. The 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.

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

[0202] 1. A method for wireless communications (e.g., method 1000 as shown in FIG. 10) , comprising: receiving 1010, by a first user device in a first network configured to be in communication with a second network, early data channel (DC) information during a session initiation protocol (SIP) establishment procedure, the early DC information indicating that the early DC needs to be established; and establishing 1020, based on the early DC information, the early DC between the first user device and the second network before the SIP session is successfully established.

[0203] Corresponding to the method 1000 implemented by the first user device, a method is implemented by a network node in which the network node transmits to the first user device in the first network configured to be in communication with the second network, early DC information during SIP establishment procedure, the early DC information indicating that the early DC needs to be established; thereby causing establishment, based on the early DC information, of the early DC between the first 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.

[0204] 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.

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

[0206] 4. The method of solution 1, wherein the early DC information 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.

[0207] 5. The method of solution 1, further comprising: upon receiving the early DC information, determining whether a request for establishing the early DC is acceptable or not.

[0208] 6. The method of solution 1, further comprising: sending a SIP message including an SDP answer to bootstrap DC and an early DC acceptance indication indicating that a request for establishing the early DC is accepted.

[0209] 7. The method of solution 1, wherein the early DC information includes at least one of an early DC required indication indicating that an establishment of the early DC is required, a DC stream ID for the early DC, a DC application ID for the early DC, or a DC application URI for early DC.

[0210] 8. The method of solution 1, further comprising: downloading a DC application list through a bootstrap DC, the DC application list including one DC application corresponding to the early DC information.

[0211] 9. A method for wireless communications (e.g., method 1100 as shown in FIG. 11) , comprising: determining 1110, 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 1120, to a data channel signaling function or a media function in the network, a first message that requests to reserve media resource information for the early DC; and sending 1130, to a cell session control function in the network, a second message including an early DC information that is forwarded from the cell session control function to a user device in another network.

[0212] Corresponding to the method 1100 implemented by the IMS application server in the network, a method is implemented by a data channel signaling function or a media function in the network to receive a first message that requests to reserve media resource information for the early DC. Corresponding to the method 1100 implemented by the IMS application server in the network, a method is implemented by a cell session control function in the network to receive a second message including an early DC information that is forwarded from the cell session control function to a user device in another network.

[0213] 10. The method of solution 9, 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.

[0214] 11. The method of solution 9, further comprising: retrieving, from user subscription data, an early DC service profile indicating whether the user device has subscribed early DC related services, wherein the determining determines that the early DC is required for the SIP session is made based on the early DC service profile.

[0215] 12. The method of solution 11, wherein the early DC service profile includes at least one of i) a general early DC subscribed indication that is used to indicate the early DC related service is subscribed; ii) early DC for CAT service is subscribed; or iii) early DC for CRS service is subscribed.

[0216] 13. The method of solution 9, further comprising: acknowledging a service requirement for the early DC, wherein the determining determines that the early DC is required for the SIP session is made based on the service requirement for the early DC.

[0217] 14. The method of solution 9, wherein the second message includes an SDP answer for a bootstrap data channel.

[0218] 15. The method of solution 9, wherein the early DC information includes at least one of an early DC required indication indicating that an establishment of the early DC is required, a DC stream ID for the early DC, a DC application ID for the early DC, or a DC application URI for early DC.

[0219] 16. A method of wireless communications (e.g., method 1200 as shown in FIG. 12) , comprising: receiving 1210, 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; determining early DC information; and sending 1220, 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, the media resource instruction including the early DC information.

[0220] Corresponding to the method 1200 implemented by the data channel signaling function, a method is implemented by a IMS application server to send 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 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, the media resource instruction including the early DC information. Other features of these methods are further disclosed in the various solutions listed herein.

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

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

[0223] 19. 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.

[0224] 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.

[0225] 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.

[0226] 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) .

[0227] 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.

[0228] 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.

[0229] 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 first user device in a first network configured to be in communication with a second network, early data channel (DC) information during a session initiation protocol (SIP) establishment procedure, the early DC information indicating that the early DC needs to be established; andestablishing, based on the early DC information, the early DC between the first 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.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 early DC information 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, further comprising:upon receiving the early DC information, determining whether a request for establishing the early DC is acceptable or not.6.The method of claim 1, further comprising:sending a SIP message including an SDP answer to bootstrap DC and an early DC acceptance indication indicating that a request for establishing the early DC is accepted.7.The method of claim 1, wherein the early DC information includes at least one of an early DC required indication indicating that an establishment of the early DC is required, a DC stream ID for the early DC, a DC application ID for the early DC, or a DC application URI for early DC.8.The method of claim 1, further comprising:downloading a DC application list through a bootstrap DC, the DC application list including one DC application corresponding to the early DC information.9.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 or a media function in the network, a first message that requests to reserve media resource information for the early DC; andsending, to a cell session control function in the network, a second message including an early DC information that is forwarded from the cell session control function to a user device in another network.10.The method of claim 9, further comprising:receiving, from a user device in the network, an 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.11.The method of claim 9, further comprising:retrieving, from user subscription data, an early DC service profile indicating whether the user device has subscribed early DC related services,wherein the determining determines that the early DC is required for the SIP session is made based on the early DC service profile.12.The method of claim 11, wherein the early DC service profile includes at least one of i) a general early DC subscribed indication that is used to indicate the early DC related service is subscribed; ii) early DC for CAT service is subscribed; or iii) early DC for CRS service is subscribed.13.The method of claim 9, further comprising:acknowledging a service requirement for the early DC,wherein the determining determines that the early DC is required for the SIP session is made based on the service requirement for the early DC.14.The method of claim 9, wherein the second message includes an SDP answer for a bootstrap data channel.15.The method of claim 9, wherein the early DC information includes at least one of an early DC required indication indicating that an establishment of the early DC is required, a DC stream ID for the early DC, a DC application ID for the early DC, or a DC application URI for early DC.16.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;determining early DC information; 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, the media resource instruction including the early DC information.17.The method of claim 16, wherein the request includes an IMS session event notification including an early DC required indication indicating that the early DC establishment is required.18.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.19.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