Methods and systems for data channel establishment in IP multimedia subsystem
Patent Information
- Application Number
- PCT/CN2025/096869
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-05-23
- Publication Date
- 2026-10-01
Smart Images

Figure CN2025096869_01102026_PF_FP_ABST
Abstract
Description
METHODS AND SYSTEMS FOR DATA CHANNEL ESTABLISHMENT IN IP MULTIMEDIA SUBSYSTEMTECHNICAL 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 meet 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 a data channel in IP multimedia subsystem (IMS) are provided.
[0004] One example aspect of the present disclosure relates to a method of digital communications, and more specifically, to a method for data channel (DC) establishment in IMS. The method may be applied to user equipment (UE) . The method comprises: sending, to an IP Multimedia Subsystem (IMS) network by the UE, a session description protocol (SDP) offer for a data channel, the SDP offer including first quick user datagram protocol internet connections (QUIC) parameters for data channel establishment; receiving, from the IMS network at the UE, an SDP answer for the data channel, the SDP answer including second QUIC parameters for data channel establishment; and establishing, by the UE, a QUIC connection between the UE and a remote side based on the first and second QUIC parameters, wherein the QUIC connection is configured to communicate media content through the data channel between the UE and the remote side.
[0005] Another example aspect of the present disclosure relates to a method of digital communications, and more specifically, to a method for data channel (DC) establishment in IMS. The method may be applied to an IP Multimedia Subsystem Application Server (IMS AS) in an IP Multimedia Subsystem (IMS) network. The method comprises: receiving, from a user equipment (UE) at the IMS AS in the IMS network, a session description protocol (SDP) offer for a data channel, wherein the SDP offer includes first quick user datagram protocol internet connections (QUIC) parameters for data channel establishment; requesting, by the IMS AS from a data channel signaling function (DCSF) in the IMS network, media resource information for the data channel by providing the first QUIC parameters; requesting, by the IMS AS from a media function (MF) in the IMS network, allocation of media resources for the data channel by providing the first QUIC parameters; and sending, by the IMS AS to the UE, an SDP answer for the data channel, wherein the SDP answer includes second QUIC parameters for data channel establishment, wherein the second QUIC parameters enable establishment of a QUIC connection between the UE and a remote side, and wherein the QUIC connection is configured to communicate media content through the data channel between the UE and the remote side.
[0006] A further example aspect of the present disclosure relates to a method of digital communications, and more specifically, to a method for data channel (DC) establishment in IMS. The method may be applied to a Data Channel Signaling Function (DCSF) in an IP Multimedia Subsystem (IMS) network. The method comprises: receiving, from an IP Multimedia Subsystem Application Server (IMS AS) at the DCSF in the IMS network, a request to reserve media resource information for a data channel, wherein the request includes first quick user datagram protocol internet connections (QUIC) parameters for data channel establishment from a session description protocol (SDP) offer sent by a user equipment (UE) ; determining, by the DCSF, to add a Media Function (MF) to a media path of the data channel; and sending, by the DCSF to the IMS AS, media resource instruction for the data channel, wherein the media resource instruction indicates an MF side media resource requirement that is to be used by the MF to allocate second QUIC parameters for data channel establishment, and wherein the second QUIC parameters are to be included in an SDP answer to the UE.
[0007] A still further example aspect of the present disclosure relates to a method of digital communications, and more specifically, to a method for data channel (DC) establishment in IMS. The method may be applied to a Media Function (MF) in an IP Multimedia Subsystem (IMS) network. The method comprises: receiving, from an IP Multimedia Subsystem Application Server (IMS AS) at the MF in the IMS network, a request to allocate media resources for a data channel, wherein the request includes first quick user datagram protocol internet connections (QUIC) parameters for data channel establishment from a session description protocol (SDP) offer sent by a user equipment (UE) ; allocating, by the MF, media resources for the data channel, including generating second QUIC parameters for data channel establishment, wherein the second QUIC parameters represent a media endpoint at the MF side; sending, by the MF to the IMS AS, the allocated media resources information including the second QUIC parameters for data channel establishment to be included in an SDP answer to the UE; receiving, by the MF, a QUIC connection establishment request from the UE based on the second QUIC parameters included in the SDP answer sent to the UE; and establishing, by the MF, a QUIC connection with the UE using the first and second QUIC parameters, wherein the QUIC connection is configured to communicate media content through the data channel between the UE and a remote side, and wherein the MF is anchored in the media path of the data channel.
[0008] 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 the methods described herein.
[0009] In another example aspect, the various techniques described herein may be embodied in the form of at least one computer-readable medium that stores processor-executable code that, upon execution by one or more processors, cause an apparatus to implement the methods described herein.
[0010] 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
[0011] FIG. 1 shows an example of an IP Multimedia Subsystem (IMS) architecture supporting data channel service.
[0012] FIG. 2 shows a media path established for data channel between two UEs or between the UE and the network, according to embodiments of the present technology.
[0013] FIG. 3 shows a protocol stack where MF acting as HTTP Proxy, according to embodiments of the present technology.
[0014] FIG. 4 shows a protocol stack where media function (MF) acting as UDP Proxy, according to embodiments of the present technology.
[0015] FIG. 5 shows a protocol stack where MF acting as DC Application Proxy, according to embodiments of the present technology.
[0016] FIG. 6 shows an example of a procedure flow for establishing a bootstrap data channel (BDC) in a person-to-person (P2P) use case, according to embodiments of the present technology.
[0017] FIG. 7 shows an example of a procedure flow for establishing an application data channel (ADC) in a person-to-person use case, according to embodiments of the present technology.
[0018] FIG. 8 shows an example of a procedure flow to establish a BDC over QUIC in P2P use case, according to embodiments of the present technology.
[0019] FIG. 9 shows an example of a procedure flow to establish an ADC over QUIC in P2P use case, according to embodiments of the present technology.
[0020] FIG. 10 shows an example of an IMS registration procedure, according to embodiments of the present technology.
[0021] FIG. 11 is a block diagram example of a wireless communication system, according to some embodiments of the present technology.
[0022] FIG. 12 is a block diagram of an example of a wireless communication apparatus , according to some embodiments of the present technology.
[0023] FIGS. 13-16 are example flowcharts of a wireless communication method based on some implementations of the disclosed technology.DETAILED DESCRIPTION
[0024] The disclosed technology provides implementations and examples for data channel establishment during an IMS session.
[0025] IP Multimedia Subsystem (IMS) data channel (DC) has been developed as a flexible method to provide enrich media content exchange with full interactive user experience. The IMS data channel is a kind of transmission container that allows dynamically download service applications and contents to the user terminal where the service applications are organized in script based applets (i.e. HTML+CSS+Javascript+JSON) . Such light weight applet can provide real interactive user experience, high definition audio / voice content, and Augmented Reality (AR) content if needed.
[0026] Two kinds of data channels are defined in IMS data channel service: (a) the bootstrap data channel (BDC) and the application data channel (ADC) . The BDC is the data channel through which the bootstrap application is running. The ADC is the data channel through which a specific data channel application is running. The bootstrap application provides an entry to load various data channel applications.
[0027] Current IMS data channel based on the WebRTC technology utilizes Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) as transport protocol. However, given the maturity and popularity of Quick User Datagram Protocol Internet Connections (QUIC) , the IMS data channel could be established on top of QUIC protocol. With the QUIC as transport protocol, the IMS data channel can archive the advantages of the QUIC, such as fast connection setup, easy Network Address Translation (NAT) traversal, Head-of-Line blocking (HOL) blocking avoidance, multiplexing streams, build-in encryption, etc.
[0028] This disclosure provides methods to establish data channels utilizing QUIC as transport protocol.
[0029] FIG. 1 shows the IMS architecture with data channel support. In the above architecture shown in FIG. 1, there are the following network functions:
[0030] 1) UE, User Equipment.
[0031] 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) .
[0032] 3) P-CSCF, Proxy CSCF. The first contact point for the user equipment (UE) within the IMS core network.
[0033] 4) S-CSCF, Serving CSCF. The entity in the IMS core network that handles the call session states.
[0034] 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.
[0035] 6) PCF, Policy Control Function. The PCF provides QoS policy rules for an IMS session.
[0036] 7) IMS AS, IMS Application Server. The IMS AS is a SIP based application server which provides IMS service logic.
[0037] 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.
[0038] 9) IMS AGW, IMS Access Media Gateway. The IMS AGW provides media security between the UE and the IMS core network.
[0039] 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 Media Resource Function (MRF) also provides the data channel media control functionality.
[0040] 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.
[0041] 12) DCAS, Data Channel Application Server. The DCAS provides application logic for a specific data channel application.
[0042] To support the regulation requirement in the IMS data channel service, the MF is required to be inserted into the media path of the data channel, so that the MF can understand the media content sent from / received by the UE.
[0043] FIG. 2 shows the media path established for data channel between two UEs or between the UE and the network, typically listed as following:
[0044] 1) For BDC of originating UE, the data channel media path is established between the originating UE (i.e. UE#1) and the originating MF and the originating DCSF.
[0045] 2) For BDC of terminating UE, the data channel media path is established between the originating DCSF and the originating MF and the terminating UE (i.e. UE#2) .
[0046] 3) For P2P (Person-to-Person or Peer-to-Peer) data channel, the ADC media path is established between the originating UE (i.e. UE#1) and the originating MF and the terminating UE (i.e. UE#2) .
[0047] 4) For P2A (Person-to-Application) data channel, the ADC media path is established between the originating UE (i.e. UE#1) and the originating MF and the originating DCAS.
[0048] 5) For A2P (Application-to-Person) data channel, the ADC media path is established between the originating DCAS and the originating MF and the originating UE (i.e. UE#1) .
[0049] 6) For P2A2P (Person-to-Application-to-Person) data channel, the ADC media path is established between the originating UE (i.e. UE#1) and the originating MF and the originating DCAS (and the originating MF) and the terminating UE (i.e. UE#2) .
[0050] To anchor the data channel media to the MF, the MF may act as either the HTTP Proxy, the UDP proxy or the DC Application proxy, respectively shown in FIGS. 3, 4, and 5.
[0051] FIG. 3 shows the protocol stack where MF acting as HTTP Proxy.
[0052] In this configuration, MF supports terminating DTLS with HTTP traffic being transparent to MF. When acting as HTTP Proxy, MF reserves media resources on both the UE side and on the MDC1 / MDC2 side allowing to send HTTP traffic to the DC Application Server. This mode is deployed both for BDC and HTTP ADC.
[0053] When used with HTTP ADC, the downloaded data channel application will in this case communicate with the DCAS, using basic HTTP, within the same bootstrap SCTP association as in which this application was downloaded. UDP, TCP, and SCTP should be supported as the transport layer protocols for MDC2.
[0054] FIG. 4 shows the protocol stack where MF acting as UDP Proxy.
[0055] In this configuration, MF transparently proxies HTTP traffic to its target. When acting as UDP Proxy, the media resources reserved by MF contain MF connection information (e.g. IP addresses and port numbers) . This mode is deployed only for ADCs, providing a P2A / A2P / P2P data channel application.
[0056] FIG. 5 shows the protocol stack where MF acting as DC Application Proxy.
[0057] In this configuration, MF transparently proxies DC application traffic between two data channel capable UEs. When acting as DC Application Proxy, the MF terminates UDP / DTLS / SCTP towards both peer UEs. This mode is deployed only for network initiated P2P ADCs.
[0058] FIG. 6 shows a procedure flow to establish a BDC in a person-to-person (P2P) use case. The MF anchors the BDC, and the originating network is offering a BDC to the remote peer, as well for application download.
[0059] The steps in the call flow are as follows:
[0060] 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 BDC establishment request with bootstrap DC stream ID. In this example procedure, the SDP contains both BDC offers for originating side and terminating side.
[0061] 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.
[0062] For the value range of DC Stream ID, 0~1000 is reserved to the BDC. 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.
[0063] 2. IMS AS validates user subscription data to determine whether the data channel call request should be notified to DCSF.
[0064] 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.
[0065] 3. IMS AS notifies the DCSF of the DC call event by sending Nimsas_SessionEvent Control_Notify (SessionEstablishmentRequestEvent, Session ID, Calling ID, Called ID, Session Case, Event initiator, Media InfoList, DC Stream ID) request to the DCSF.
[0066] 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. 'served 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 BDC in this procedure.
[0067] 4. After receiving the DC control request, the DCSF determines the policy about how to process the BDC 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.
[0068] 5. The DCSF reserves MDC1 media information for the BDC. Two different MDC1 media information are reserved: the originating side MDC1 media information (targeting local UE, i.e. originating UE, for local side BDC) and the terminating side MDC1 media information (targeting remote UE, i.e. terminating UE, for remote side BDC) .
[0069] 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 BDC with MF both for originating and terminating side. The MediaInstructionSet provided by the DSCF, 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.
[0070] In this scenario, the DCSF instructs the IMS AS to terminate BDC establishment request on originating MF, and initiate remote BDC establishment request (targeting remote UE) as well as forwarding remote BDC establishment request of served user (targeting remote DCSF) towards terminating network.
[0071] 7. The IMS AS selects a MF based on local configuration or discovers and selects a MF supporting DC media function via NRF.
[0072] 8. IMS AS invokes Nmf_MRM_Create (List of Media Termination Descriptors) service operation to instruct MF to allocate required data channel media resources.
[0073] IMS AS requests the MF to create two different Media Terminations, one representing the BDC media of the local UE (i.e. to be offered to the originating UE) and the other representing the BDC media of the remote UE (i.e. to be offered to the terminating UE) . Each Media Termination includes information required to allocate resources in both Mb and the MDC1 interfaces.
[0074] 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.
[0075] The MF media resource allocation in step 8 could be done with one or multiple service invocations.
[0076] 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.
[0077] 10. The DCSF stores the media resource information and responds to the Notify Request received in step 3.
[0078] 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 BDC to UE#2 is included.
[0079] 14. UE#2 and terminating network returns an 18X response (e.g. "183 Session Progressing" or "180 Ring" ) with the SDP answer to BDC to originating network.
[0080] 15. UE#1 and originating network respond Provisional Response ACKnowledgement (PRACK) .
[0081] 16. UE#2 and terminating network sends 200 OK to PRACK, to confirm success of SDP media negotiation.
[0082] 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.
[0083] 17-18. SIP UPDATE may be invoked to negotiate new SDP media between originating UE and terminating UE.
[0084] 19-20: UE#2 and terminating network returns a 200 OK response to SIP INVITE.
[0085] 21. The IMS AS notifies the successful session establishment event, Nimsas_SessionEvent Control Notify (SessionEstablishmentSuccessEvent, Session ID, Media Info List) to DCSF.
[0086] 22. The DCSF responds to the Nimsas notification request.
[0087] 23.200 OK forwarded to UE#1 which indicates the BDC has been established.
[0088] 24. The originating network P-CSCF executes QoS procedure for BDC as specified in 3GPP TS 23.203 and 3GPP TS 23.503.
[0089] 25-28: The BDCs 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 BDC 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.
[0090] 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.
[0091] The BDCs 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.
[0092] 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 BDCs.
[0093] IMS-AGW needs to allow the establishment of BDCs based on the information in the 200 OK to PRACK and UPDATE messages.
[0094] 29. Subsequent procedures continue.
[0095] Using the procedure described in FIG. 6, the originating UE initiates BDC establishment with the terminating UE, and subsequently both the originating UE and terminating UE can download the DC applications from the established BDC. Later, the originating UE can initiates ADC establishment with the terminating UE, so as to run a specific data channel application between the two sides.
[0096] FIG. 7 describes a procedure flow to establish an ADC in a person-to-person use case. In this scenario, the MF is not used to anchor the ADC.
[0097] In the call flow 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.
[0098] The steps in the call flow are as follows:
[0099] 0. IMS session and BDC have been established. Selected data channel application (s) have been downloaded to UE#1 and possibly UE#2.
[0100] 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 BDC information, as well as the requested ADC and the associated DC application binding information, according to 3GPP TS 26.114.
[0101] 2. The IMS AS validates user subscription data to determine whether the media change request event should be notified to the DCSF.
[0102] 3. The IMS AS notifies the DCSF, via Nimsas_SessionEventControl_Notify (MediaChange Request Event, Session ID, Session Case, Event initiator, Media Info List) of the media change request event.
[0103] 4. After receiving the session event notification, the DCSF determines the policy about how to process the ADC establishment request based on the related parameters (i.e. associated DC application binding information) in the notification and / or DCSF service specific policy.
[0104] 5. The DCSF determines that the added ADC media descriptor of the SDP offer takes UE#2 as a target endpoint and does not require anchoring on the local MF. If MF needs to anchor ADC, DCSF would have used the Nimsas_MediaControl service operation to instruct IMS AS to allocate data channel media resources of the MF.
[0105] 6. DCSF responds to the notification received in step 3.
[0106] 7-8. IMS AS sends the re-INVITE to the originating S-CSCF and then to the terminating network side and UE#2.
[0107] 9-11. UE#2 and terminating network returns a 200 OK response with SDP answer for ADC 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.
[0108] The UE at the terminating side is capable to determine if to use the DC application based on the received DC application binding information.
[0109] 12. IMS AS notifies the DCSF of the successful data channel modification.
[0110] 13. DCSF responds to the notification received in step 12.
[0111] 14-15. The IMS AS sends 200 OK response to the originating S-CSCF and P-CSCF.
[0112] 16. The originating network P-CSCF executes QoS procedure for ADC media based on the SDP answer information from the 200 OK response.
[0113] 17. P-CSCF returns the 200 OK response to UE#1.
[0114] 18. UE#1 sends ACK to the terminating network.
[0115] 19. The ADC between UE#1 and UE#2 is established. In this example, it is not anchored in MF / MRF.
[0116] During the data channel establishment procedure, the originating UE shall indicate the parameters used for the requested data channel in the SDP offer, e.g. its IP address used for SCTP connection, the UDP port, the SCTP port, the stream id of BDC (s) , the Transport Layer Security (TLS) ID, the figureprint of the DTLS, etc.
[0117] Taking BDC establishment as example, when the originating UE requests to establish the BDC, it shall carry the SDP offer for BDC, in the step 1 of FIG. 6. The following table shows an example of the SDP offer for BDC, focusing on the typical parameters:
[0118] In the SDP offer example, the m line indicates the originating UE requests to establish a media path for "webrtc-datachannel" application using "UDP / DTLS / SCP" protocol. The "a=sctp-port: 5000" attributes indicates the SCTP port used by the BDC. The "a=dcmap: 0" attribute indicates the BDC for originating side (for UE#1) is required, and the "a=dcmap: 100" indicates the BDC for terminating side (for UE#2) is also required. When receiving the SDP answer for BDC, the originating UE checks the parameters and detects if the BDC is successfully established. For example, if the SDP answer indicates the "a=dcmap: 0" the originating UE thus detects the success of the BDC for the originating UE, and if the "a=dcmap: 100" is indicated the originating UE detects the BDC for terminating UE is successfully established.
[0119] To utilize the QUIC as a transport protocol for IMS data channel, updates to existing procedure are desirable. To support the data channel over QUIC, it needs the UE, the DCSF, and the MF to negotiate and exchange the QUIC connection parameters, e.g., via the SDP negotiation.
[0120] Embodiment 1: QUIC based BDC establishment in P2P
[0121] In this embodiment, the negotiation of QUIC based BDC establishment via the SDP negotiation.
[0122] FIG. 8 shows the procedure flow to establish a BDC over QUIC in P2P use case. In this procedure, the MF is inserted into the media path of the data channel and terminates the QUIC connection from the UE to the network. The MF may further set up another QUIC connection towards the DCSF. Once the MF is inserted into the BDC path between the UE and the DCSF, the MF actually operates as a QUIC proxy.
[0123] FIG. 8 has similar steps as FIG. 6, with the following changes. For the steps in FIG. 8 that are not described herein, the corresponding descriptions provided for the steps in FIG. 6 apply and are not repeated here for brevity.
[0124] 1. UE#1 sends the SIP INVITE request with an initial SDP to the IMS AS, carrying the SDP offer for BDC, similar as step 1 of FIG. 6 procedure.
[0125] In this step, as the UE#1 requests to set up the BDC over UDP / QUIC, it carries necessary information to indicate that QUIC is used for data channel establishment. The SDP offer (e.g. in the m line) shall indicate the data channel (i.e. the BDC in this procedure) requires UDP / QUIC as transport protocol. For example, in the m line it indicates "UDP / QUIC" as transport protocol (in the case only QUIC is utilized to carry the media content) or indicates "UDP / QUIC / MoQ" as transport protocol (in the case that Media over QUIC (MoQ) is utilized to carry the media content) .
[0126] The originating UE may indicate its IP address and UDP port used for QUIC connection establishment. If Interactive Connectivity Establishment (i.e. ICE) is not used, the originating UE needs to provide its IP address and UDP port used for QUIC connection establishment. Otherwise, if ICE is utilized for NAT traversal, the UE needs to provide a list of candidate IP address and UDP port for QUIC connection set up.
[0127] If the originating UE has decided the QUIC Connection ID (s) to be used (e.g. source QUIC CID, destination QUIC CID) , it can indicate the QUIC CID (s) in the SDP offer. For example, the "a=s-cid" attribute is used to indicate the source QUIC CID at the UE side, while the "a=d-cid" attribute is used to indicate the destination QUIC CID at the remote server (i.e. at the QUIC server in the IMS network, e.g. the DCSF or MF) . The originating UE may pre-allocate the destination QUIC CID for the remote server and such QUIC CID may be later updated by the remote server. The originating UE may only indicate the source QUIC CID but not provide the destination QUIC CID, and in this case the remote server allocates its own QUIC CID) .
[0128] If the originating UE has allocated the MSID (i.e. media stream ID) for the media stream within the QUIC connection for BDC, the UE may indicate the MSID for BDC in the SDP offer (e.g. indicating the "a=msid: bdc" ) . Especially, if multiplex in QUIC or MoQ is utilized for different data channels, the MSID used for BDC needs to be indicated.
[0129] If MoQ is utilized to carry the media content, the MSID can refer to the MoQ Media ID (i.e. MID) of the MoQ media track carrying the media content of the data channel. If just QUIC is utilized to carry the media content, the MSID can refer to the QUIC Stream ID of the QUIC stream carrying the media content of the data channel.
[0130] The QUIC CID (s) provided by the originating UE might be used by the P-CSCF to instruct the PCF to perform policy authorization specific for QUIC. If multiplex in QUIC or MoQ is utilized for data channels, the MSID is required for policy authorization.
[0131] Table 2 shows the example of the SDP offer for BDC over QUIC, without requiring ICE (i.e. no NAT traversal required) .
[0132] Table 3 shows the example of the SDP offer for BDC over QUIC, requiring ICE for NAT traversal.
[0133] 3. IMS AS notifies the DCSF of the DC call event, similar as step 3 of FIG. 6 procedure.
[0134] In this step, the Media Info List includes the media component for BDC that requires the UDP / QUIC as transport protocol, i.e. the transport protocol type is set to "UDP / QUIC" .
[0135] 4. After receiving the DC control request, the DCSF determines the policy about how to process the BDC 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. The MSID indicated in the SDP offer represents the QUIC media stream (or MoQ media stream) that is used to transport the DC stream identified by the DC Stream ID.
[0136] 5. The DCSF reserves MDC1 media information for the BDC, similar as step 5 of FIG. 6 procedure.
[0137] In this step, the DCSF determines the MF needs to anchor the media for the data channel (i.e. BDC in this procedure) , which means the QUIC connection from / towards the originating UE needs to be terminated at the originating MF.
[0138] The DCSF may further determine QUIC connection between the MF and DCSF is needed, if so 2-hops QUIC connection is needed from the originating UE to the DCSF: (a) one QUIC connection between the originating UE and the originating MF, (b) another QUIC connection between the originating MF and the originating DCSF. If so, the DCSF reserved MDC1 media information for BDC indicates the transport protocol is UDP / QUIC.
[0139] 6. DCSF invokes the Nimsas_MediaControl_MediaInstruction (Session ID, Media Instruction Set) operation to instruct the IMS AS how to set up BDC with MF, similar as step 6 of FIG. 6.
[0140] In this step, within the Media Instruction Set the media instruction for BDC indicates the transport protocol is UDP / QUIC.
[0141] 8. IMS AS invokes Nmf_MRM_Create (List of Media Termination Descriptors) service operation to instruct MF to allocate required data channel media resources, similar as step 8 of FIG. 6.
[0142] In this step, the media termination descriptor of the BDC for originating UE carries the originating UE side Mb endpoint information that is received in the SDP offer in step 1, e.g. UDP / QUIC as transport protocol, originating UE's IP address, originating UE's UDP port used for QUIC connection, source QUIC Connection ID, destination QUIC Connection ID, MSID for BDC, etc.
[0143] In this step, the media termination descriptor of the BDC for terminating UE is set to null, since the IMS AS has not yet got the SDP answer from the terminating UE.
[0144] In this step, as the BDC requires UDP / QUIC as transport protocol, for each media termination, the MF allocates the media resources of UDP / QUIC protocol for the bootstrap strap data channel. For example, for the Mb endpoint at the MF side, the MF indicates the UDP / QUIC as transport protocol, assigns the UDP port for QUIC connection (e.g. default port 443 for UDP / QUIC / HTTP3, or any server determined UDP port e.g. 65432) . In addition, the MF may indicate its own QUIC Connection ID, e.g. if it doesn't accept the originating UE allocated server side QUIC Connection ID.
[0145] 9. IMS AS responds to the MediaInstruction request received in step 6, similar as step 9 of FIG. 6.
[0146] In this step, the IMS AS includes the MDC1 endpoint at the MF side, and the MDC1 endpoint contains the UDP / QUIC information provided by the MF.
[0147] 11-13. IMS AS sends the INVITE which includes the updated SDP offer to remote network side and UE#2, similar as step 11-13 of FIG. 6.
[0148] In this step, the IMS AS includes the media resource info of the BDC for terminating UE (i.e. UE#2) in the SDP offer, including the MF's Mb endpoint for terminating UE.
[0149] The updated SDP offer is similar as table 2 or table 3, with the UDP / QUIC information replaced with the MF's UDP / QUIC information of the BDC (i.e. the MF's Mb endpoint information) .
[0150] 14. UE#2 and terminating network returns an 18X response (e.g. "183 Session Progressing" or "180 Ring" ) with the SDP answer to BDC to originating network.
[0151] In this step, if UE#2 accepts the BDC over QUIC, it indicates its own UDP / QUIC information of the BDC in the SDP answer. The SDP answer from UE#2 is similar as table 2 or table 3, with the UDP / QUIC information replaced with the terminating UE's UDP / QUIC information of the BDC (i.e. the terminating UE's Mb endpoint information) .
[0152] In this step, when the IMS AS receives SDP answer from the UE#2, it updates the SDP answer to replace the terminating UE's BDC information with the MF's BDC information, i.e. replace the terminating UE's Mb endpoint with the MF's endpoint for the originating UE.
[0153] Table 4 shows the example of the SDP answer for BDC over QUIC, sent from IMS AS to originating UE, without requiring ICE (i.e. no NAT traversal required) .
[0154] Table 5 shows the example of the SDP answer for BDC over QUIC, sent from IMS AS to originating UE, requiring ICE for NAT traversal.
[0155] 25: The BDC has been established between originating MF and UE#1, similar as step 25 of FIG. 6.
[0156] In this step, the originating UE utilizes the UDP / QUIC information in the SDP answer for the BDC (in step 14) to set up QUIC connection towards the originating MF. After that, the originating UE can send HTTP request to the originating MF to download the data channel application list through the BDC.
[0157] 26: The BDC has been established between originating MF and UE#2, similar as step 26 of FIG. 6.
[0158] In this step, the terminating UE utilizes the UDP / QUIC information in the SDP offer for the BDC (in step 12) to set up QUIC connection towards the originating MF. After that, the terminating UE can send HTTP request to the originating MF to download the data channel application list through the BDC.
[0159] Embodiment 2: ADC establishment over QUIC in P2P case
[0160] In this embodiment, the negotiation of ADC establishment over UDP / QUIC transport is via the SDP negotiation.
[0161] FIG. 9 shows a procedure flow to establish an ADC over QUIC in P2P use case. In this procedure, the MF is not required to be inserted into the media path of the application data channel between the originating UE and the terminating UE.
[0162] FIG. 9 has similar steps as FIG. 7, with the following changes. For the steps in FIG. 9 that are not described herein, the corresponding descriptions provided for the steps in FIG. 7 apply and are not repeated here for brevity.
[0163] 1. UE#1 sends the SIP reINVITE request with an updated SDP to IMS AS, similar as step 1 of FIG. 7.
[0164] In this step, the SDP offer for ADC contains the UDP / QUIC information used to establish the ADC.
[0165] The originating UE may indicate its IP address and UDP port used for QUIC connection establishment. If Interactive Connectivity Establishment (i.e. ICE) is not used, the originating UE needs to provide its IP address and UDP port used for QUIC connection establishment. Otherwise, if ICE is utilized for NAT traversal, the UE needs to provide a list of candidate IP address and UDP port for QUIC connection set up.
[0166] If the originating UE has decided the QUIC Connection ID (s) to be used (e.g. source QUIC CID, destination QUIC CID) , it can indicate the QUIC Connection ID (s) in the SDP offer (e.g. indicating "a=s-cid" and / or "a=d-cid" attributes) .
[0167] If the originating UE has allocated the MSID (i.e. media stream ID) for the media stream within the QUIC connection for BDC, the UE may indicate the MSID for BDC in the SDP offer (e.g. indicating the "a=msid: bdc" ) . Especially, if multiplex in QUIC or MoQ is utilized for different data channels, the MSID used for BDC needs to be indicated.
[0168] If the originating UE has allocated the MSID (i.e. media ID) for the media stream within the QUIC connection for ADC, the UE may indicate the MSID for ADC in the SDP offer (e.g. indicating the "a=msid: adc<dc-application-name>" ) . Especially, if multiplex in QUIC or MoQ is utilized for different data channels, the MSID used for ADC needs to be indicated.
[0169] If MoQ is utilized to carry the media content, the MSID can refer to the MoQ Media ID (i.e. MID) of the MoQ media track carrying the media content of the data channel. If just QUIC is utilized to carry the media content, the MSID can refer to the QUIC Stream ID of the QUIC stream carrying the media content of the data channel.
[0170] 10. UE#2 and terminating network returns a 200 OK response with SDP answer for ADC to originating network.
[0171] In this step. The SDP answer for ADC contains the UDP / QUIC information used to establish QUIC connection between the originating UE and the terminating UE. The UDP / QUIC information carried in the SDP answer is similar as those information carried by the originating UE in step 1.
[0172] Embodiment 3: Feature Support for DC over QUIC
[0173] In this embodiment, before the originating UE tries to establish data channel over QUIC, it needs to detect if the IMS network supports this feature of data channel over QUIC.
[0174] FIG. 10 shows an example of an IMS registration procedure where the UE negotiates the feature of a data channel over QUIC with the IMS network.
[0175] Once the UE selects a P-CSCF, it initiates IMS registration. The IMS registration procedure is utilized to negotiate the support of DC over QUIC between the UE and the IMS network.
[0176] 1. The UE sends SIP Registration request to the selected P-CSCF. If the UE supports data channel over QUIC (i.e. DC over QUIC) , it carries the UE capability of DC over QUIC in the SIP Registration request.
[0177] 2. The P-CSCF forwards the SIP Registration request to the S-CSCF.
[0178] 3. The S-CSCF fetches UE subscription data from the HSS. The UE subscription data may indicate whether the UE is subscribed with IMS data channel service.
[0179] 4. If third party registration is required, as indicated by the UE subscription data, the S-CSCF triggers third party registration to the corresponding SIP AS.
[0180] 5. If the registration is successful, the S-CSCF returns SIP 200 OK to the P-CSCF.
[0181] If the IMS network supports DC over QUIC, the S-CSCF indicates the network (NW) capability of DC over QUIC in the SIP 200 OK.
[0182] 6. The P-CSCF returns SIP "200 OK" response to the UE, with the NW capability of DC over QUIC.
[0183] In order to avoid unnecessary complexity, it assumes homogenous support of DC over QUIC in the entire IMS network, including the P-CSCF, S-CSCF, the IMS AS, the MF and the DCSF. This assumption applies to the non-roaming case. However, in roaming case, as the P-CSCF is not in the HPLMN, the P-CSCF needs to indicate its own support of DC over QUIC in the step 2, so that the S-CSCF can determine if to indicate NW capability of DC over QUIC in step 5, taking into account of the P-CSCF capability. Otherwise, if other IMS entities support the feature while the P-CSCF does not, it will cause problem to the media resource reservation between the P-CSCF and the PCF.
[0184] With the capability negotiation between the UE and the IMS network on DC over QUIC, the UE thus knows it can request the QUIC based data channel establishment towards the IMS network. Thus the procedure described in FIG. 8 and FIG. 9 can be implemented.
[0185] The above procedures are targeting how to establish data channels utilizing the QUIC (or MoQ) as transport protocol. This method (i.e. exchange of QUIC endpoint information and media stream information in the SDP offer and SDP answer) can also be extended to normal media (e.g. audio, video, etc. ) set up in the IMS session. In this case the SDP offer / SDP answer can also indicate the necessary parameters for media transmission over QUIC (or MoQ) , e.g. indicating the UDP / QUIC or UDP / QUIC / MoQ as transport protocol, indicating the UDP port for QUIC connection, indicating the QUIC CID (s) , indicating the MSID (s) of the media stream carrying one specific media content, etc.
[0186] FIG. 11 is a block diagram example of a wireless communication system, according to some embodiments. FIG. 11 shows an example of a wireless communication system (e.g., a long term evolution (LTE) , 5G or NR cellular network) that includes a base station BS 120 and one or more user equipment (UE) 111, 112 and 113. In some embodiments, the uplink transmissions (131, 132, 133) can include uplink control information (UCI) , higher layer signaling (e.g., UE assistance information or UE capability) , or uplink information. In some embodiments, the downlink transmissions (141, 142, 143) can include downlink control information, DCI or medium access control (MAC) information or high layer signaling or downlink information. The UE may be, for example, a smartphone, a tablet, a mobile computer, a machine to machine (M2M) device, a terminal, a mobile device, an Internet of Things (IoT) device, and so on. Various core network functions depicted in FIG. 9 may be communicatively coupled (directly or indirectly) to the BS 120.
[0187] FIG. 12 is a block diagram representation of a portion of an apparatus, in accordance with some embodiments of the presently disclosed technology. An apparatus 1210 such as a network device or a base station or a wireless device (or UE) , can include processor electronics 1220 such as a microprocessor that implements one or more of the techniques presented in this document. The apparatus 1210 can include transceiver electronics 1230 to send and / or receive wireless signals over one or more communication interfaces such as antenna (s) 1240. The apparatus 1210 can include other communication interfaces for transmitting and receiving data. Apparatus 1210 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 1220 can include at least a portion of the transceiver electronics 1230. In some embodiments, at least some of the disclosed techniques, modules or functions are implemented using the apparatus 1210.
[0188] Some embodiments may include the following solutions.
[0189] Solution 1. A method of digital communications, and more specifically, to a method for data channel (DC) establishment in IMS. The method may be applied to user equipment (UE) (e.g., process 1300 as shown in FIG. 13) . The method (e.g., process 1300) comprises: sending 1310, to an IP Multimedia Subsystem (IMS) network by the UE, a session description protocol (SDP) offer for a data channel, the SDP offer including first quick user datagram protocol internet connections (QUIC) parameters for data channel establishment; receiving 1320, from the IMS network at the UE, an SDP answer for the data channel, the SDP answer including second QUIC parameters for data channel establishment; and establishing, by the UE, a QUIC connection between the UE and a remote side based on the first and second QUIC parameters 1330, wherein the QUIC connection is established to communicate media content through the data channel between the UE and the remote side.
[0190] Solution 2. A method of digital communications, and more specifically, to a method for data channel (DC) establishment in IMS. The method may be applied to an IP Multimedia Subsystem Application Server (IMS AS) in an IP Multimedia Subsystem (IMS) network (e.g., process 1400 as shown in FIG. 14) . The method (e.g., process 1400) comprises: receiving 1410, from a user equipment (UE) at the IMS AS in the IMS network, a session description protocol (SDP) offer for a data channel, wherein the SDP offer includes first quick user datagram protocol internet connections (QUIC) parameters for data channel establishment; requesting 1420, by the IMS AS from a data channel signaling function (DCSF) in the IMS network, media resource information for the data channel by providing the first QUIC parameters; requesting 1430, by the IMS AS from a media function (MF) in the IMS network, allocation of media resources for the data channel by providing the first QUIC parameters; and sending 1440, by the IMS AS to the UE, an SDP answer for the data channel, wherein the SDP answer includes second QUIC parameters for data channel establishment, wherein the second QUIC parameters enable establishment of a QUIC connection between the UE and a remote side, and wherein the QUIC connection is established to communicate media content through the data channel between the UE and the remote side.
[0191] Solution 3. A method of digital communications, and more specifically, to a method for data channel (DC) establishment in IMS. The method may be applied to a Data Channel Signaling Function (DCSF) in an IP Multimedia Subsystem (IMS) network (e.g., process 1500 as shown in FIG. 15) . The method (e.g., process 1500) comprises: receiving 1510, from an IP Multimedia Subsystem Application Server (IMS AS) at the DCSF in the IMS network, a request to reserve media resource information for a data channel, wherein the request includes first quick user datagram protocol internet connections (QUIC) parameters for data channel establishment from a session description protocol (SDP) offer sent by a user equipment (UE) ; determining, by the DCSF, to add a Media Function (MF) to a media path of the data channel 1520; and sending 1530, by the DCSF to the IMS AS, media resource instruction for the data channel, wherein the media resource instruction indicates an MF side media resource requirement that is to be used by the MF to allocate second QUIC parameters for data channel establishment, wherein the second QUIC parameters are to be included in an SDP answer to the UE. The QUIC connection established based on the first and second QUIC parameters is configured to communicate media content through the data channel between the UE and a remote side and enable the MF to be anchored in the media path of the data channel between the UE and the remote side.
[0192] Solution 4. A method of digital communications, and more specifically, to a method for data channel (DC) establishment in IMS. The method may be applied to a Media Function (MF) in an IP Multimedia Subsystem (IMS) network (e.g., process 1600 as shown in FIG. 16) . The method (e.g., process 1600) comprises: receiving 1610, from an IP Multimedia Subsystem Application Server (IMS AS) at the MF in the IMS network, a request to allocate media resources for a data channel, wherein the request includes first quick user datagram protocol internet connections (QUIC) parameters for data channel establishment from a session description protocol (SDP) offer sent by a user equipment (UE) ; allocating 1620, by the MF, media resources for the data channel, including generating second QUIC parameters for data channel establishment, wherein the second QUIC parameters represent a media endpoint at the MF side; sending 1630, by the MF to the IMS AS, the allocated media resources information including the second QUIC parameters for data channel establishment to be included in an SDP answer to the UE; receiving, by the MF, a QUIC connection establishment request from the UE based on the second QUIC parameters included in the SDP answer sent to the UE 1640; and establishing, by the MF, a QUIC connection with the UE using the first and second QUIC parameters 1650, wherein the QUIC connection is established to communicate media content through the data channel between the UE and a remote side, and wherein the MF is anchored in the media path of the data channel.
[0193] Solution 5. The method of any one or more of the solutions disclosed herein, wherein the first QUIC parameters comprise QUIC parameters of the UE.
[0194] Solution 6. The method of any one or more of the solutions disclosed herein, wherein the second QUIC parameters comprise at least one of: QUIC parameters of the MF for the data channel; or QUIC parameters of a terminating UE for the data channel.
[0195] Solution 7. The method of any one or more of the solutions disclosed herein, wherein the first or second QUIC parameters for the data channel comprise: a transport protocol specification and a UDP port for the QUIC connection, wherein the transport protocol specification is one of UDP / QUIC or UDP / QUIC / MoQ.
[0196] Solution 8. The method of any one or more of the solutions disclosed herein, wherein the first or second QUIC parameters for the data channel further comprise: a QUIC connection ID (CID) of the QUIC connection for the data channel; and / or a media stream ID (MSID) of a media stream in the QUIC connection for the data channel. In some embodiments, only one of the two may be present. In some embodiments, both of the two are present. If a same IP / port used for multiplex QUIC connections, then QUIC CID is needed. If within one QUIC connection, different QUIC streams (or MoQ tracks) are used for different data channels (e.g. one for BDC and another for ADC) , then MSID is needed to indicate the QUIC stream (or MoQ track) .
[0197] Solution 9. The method of any one or more of the solutions disclosed herein, wherein the MSID indicates: an MSID of a media stream for a bootstrap data channel (BDC) , when the data channel is the BDC; and / or an MSID of a media stream for an application data channel (ADC) , when the data channel is the ADC.
[0198] Solution 10. The method of any one or more of the solutions disclosed herein, wherein when Interactive Connectivity Establishment (ICE) is utilized for Network Address Translation (NAT) traversal, the SDP offer further includes a list of candidate IP addresses and UDP ports for QUIC connection setup.
[0199] Solution 11. The method of any one or more of the solutions disclosed herein, wherein the data channel is either: a BDC through which a bootstrap application runs to provide an entry to load various data channel applications; or an ADC through which a specific data channel application runs.
[0200] Solution 12. The method of any one or more of the solutions disclosed herein, wherein the MF acts as one of: a UDP proxy transparently proxying HTTP traffic to its target; or a DC application proxy transparently proxying DC application traffic between the UE and a terminating UE. In some embodiments, QUIC or MoQ is used as the transport protocol, the MF acting as HTTP proxy terminates QUIC or MoQ traffic.
[0201] Solution 13. The method of any one or more of the solutions disclosed herein, wherein the remote side comprises one of: the MF when establishing a BDC, or a terminating UE when establishing an ADC for peer-to-peer communication.
[0202] Solution 14. The method of any one of claims 1-4, wherein the IMS network comprising at least one of: a Proxy Call Session Control Function (P-CSCF) serving as a contact point for the UE; a Serving Call Session Control Function (S-CSCF) that handles call session states; an IMS Application Server (IMS AS) that provides IMS service logic; a DCSF that provides data channel control logic; or the MF that provides media resource management and forwarding of data channel media traffic.
[0203] Solution 15. The method of any one or more of the solutions disclosed herein, wherein: the second QUIC parameters represent a media endpoint of the MF, and the SDP answer includes the second QUIC parameters containing an IP address and a UDP port of the MF for QUIC connection establishment.
[0204] Solution 16. The method of any one of claims 1-4, wherein: the data channel comprises an ADC, and the ADC is established after a BDC has been established and a data channel application has been downloaded.
[0205] Solution 17. The method of any one or more of the solutions disclosed herein, wherein: the data channel comprises an ADC, and the SDP offer includes ADC information and associated data channel (DC) application binding information that allows a terminating UE to determine whether to use a specific DC application for the ADC to be established between the UE and the terminating UE.
[0206] Solution 18. The method of any one or more of the solutions disclosed herein, wherein: the data channel comprises an ADC, and the first or second QUIC parameters include an MSID indicating a media stream for the ADC, the MSID comprising an indicator of a specific DC application.
[0207] Solution 19. The method of any one or more of the solutions disclosed herein, wherein: the data channel comprises a BDC, and the first or second QUIC parameters include an MSID indicating a media stream for the BDC.
[0208] Solution 20. The method of any one or more of the solutions disclosed herein, wherein: the DC comprises an ADC, and the MF acts as a UDP Proxy providing a person-to-application (P2A) , application-to-person (A2P) , or person-to-person (P2P) data channel application.
[0209] Solution 21. The method of any one or more of solution 1 or other solutions disclosed herein, comprising: before sending the SDP offer for the data channel, indicating UE capability of DC over QUIC to the IMS network; and receiving network capability indication of DC over QUIC from the IMS network.
[0210] Solution 22. The method of any one or more of solution 1 or other solutions disclosed herein, wherein: the data channel establishment is to establish a BDC; and establishing the QUIC connection comprises establishing the QUIC connection towards the MF; and the MF terminates the QUIC connection from the UE and sets up another QUIC connection towards a DCSF.
[0211] Solution 23. The method of any one or more of solution 1 or other solutions disclosed herein, wherein: the data channel is a BDC, and the method comprises: after establishing the QUIC connection, sending, through the BDC, an HTTP request to the MF to download a DC application list; and receiving, through the BDC, the DC application list from the MF.
[0212] Solution 24. The method of any one or more of solution 1 or other solutions disclosed herein, comprising: after establishing the QUIC connection with the MF, establishing an ADC with a terminating UE through a separate SDP offer / answer exchange, wherein the ADC uses a second QUIC connection that is established directly between the UE and the terminating UE.
[0213] Solution 25. A wireless communication apparatus comprising at least one processor configured to cause the wireless communication apparatus to implement a method of any one or more of the solutions disclosed herein.
[0214] Solution 26. At least one computer-readable medium having code stored thereon, the code, upon execution by at least one processor of an apparatus, causing the apparatus to implement a method of any one or more of the solutions disclosed herein.
[0215] 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.
[0216] 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.
[0217] 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) .
[0218] 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.
[0219] 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.
[0220] 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 of digital communications, comprising:sending, to an IP Multimedia Subsystem (IMS) network by a user equipment (UE) , a session description protocol (SDP) offer for a data channel, the SDP offer including first quick user datagram protocol internet connections (QUIC) parameters for data channel establishment;receiving, from the IMS network at the UE, an SDP answer for the data channel, the SDP answer including second QUIC parameters for data channel establishment; andestablishing, by the UE, a QUIC connection between the UE and a remote side based on the first and second QUIC parameters, wherein the QUIC connection is established to communicate media content through the data channel between the UE and the remote side.2.A method of digital communications, comprising:receiving, from a user equipment (UE) at an IP Multimedia Subsystem Application Server (IMS AS) in an IP Multimedia Subsystem (IMS) network, a session description protocol (SDP) offer for a data channel, wherein the SDP offer includes first quick user datagram protocol internet connections (QUIC) parameters for data channel establishment;requesting, by the IMS AS from a data channel signaling function (DCSF) in the IMS network, media resource information for the data channel by providing the first QUIC parameters;requesting, by the IMS AS from a media function (MF) in the IMS network, allocation of media resources for the data channel by providing the first QUIC parameters; andsending, by the IMS AS to the UE, an SDP answer for the data channel, wherein the SDP answer includes second QUIC parameters for data channel establishment, wherein the second QUIC parameters enable establishment of a QUIC connection between the UE and a remote side, and wherein the QUIC connection is established to communicate media content through the data channel between the UE and the remote side.3.A method of digital communications, comprising:receiving, from an IP Multimedia Subsystem Application Server (IMS AS) at a Data Channel Signaling Function (DCSF) in an IMS network, a request to reserve media resource information for a data channel, wherein the request includes first quick user datagram protocol internet connections (QUIC) parameters for data channel establishment from a session description protocol (SDP) offer sent by a user equipment (UE) ;determining, by the DCSF, to add a Media Function (MF) to a media path of the data channel; andsending, by the DCSF to the IMS AS, media resource instruction for the data channel, wherein the media resource instruction indicates an MF side media resource requirement that is to be used by the MF to allocate second QUIC parameters for data channel establishment, and wherein the second QUIC parameters are to be included in an SDP answer to the UE.4.A method of digital communications, the method comprising:receiving, from an IP Multimedia Subsystem Application Server (IMS AS) at a Media Function (MF) in an IMS network, a request to allocate media resources for a data channel, wherein the request includes first quick user datagram protocol internet connections (QUIC) parameters for data channel establishment from a session description protocol (SDP) offer sent by a user equipment (UE) ;allocating, by the MF, media resources for the data channel, including generating second QUIC parameters for data channel establishment, wherein the second QUIC parameters represent a media endpoint at the MF side;sending, by the MF to the IMS AS, the allocated media resources information including the second QUIC parameters for data channel establishment to be included in an SDP answer to the UE;receiving, by the MF, a QUIC connection establishment request from the UE based on the second QUIC parameters included in the SDP answer sent to the UE; andestablishing, by the MF, a QUIC connection with the UE based on the first and second QUIC parameters, wherein the QUIC connection is established to communicate media content through the data channel between the UE and a remote side, and wherein the MF is anchored in the media path of the data channel.5.The method of any one of claims 1-4, wherein the first QUIC parameters comprise QUIC parameters of the UE.6.The method of any one of claims 1-4, wherein the second QUIC parameters comprise at least one of:QUIC parameters of the MF for the data channel; orQUIC parameters of a terminating UE for establishing the data channel between the UE and the terminating UE.7.The method of any one of claims 1-4, wherein the first or second QUIC parameters for the data channel comprise: a transport protocol specification and a UDP port for the QUIC connection, wherein the transport protocol specification is one of UDP / QUIC or UDP / QUIC / MoQ.8.The method of any one of claims 1-4, wherein the first or second QUIC parameters for the data channel comprise at least one of:a QUIC connection ID (CID) of the QUIC connection for the data channel; ora media stream ID (MSID) of a media stream in the QUIC connection for the data channel.9.The method of claim 8, wherein the MSID indicates:an MSID of a media stream for a bootstrap data channel (BDC) , when the data channel is the BDC; and / oran MSID of a media stream for an application data channel (ADC) , when the data channel is the ADC.10.The method of any one of claims 1-4, wherein:Interactive Connectivity Establishment (ICE) is utilized for Network Address Translation (NAT) traversal, andthe SDP offer includes a list of candidate IP addresses and UDP ports for QUIC connection setup.11.The method of any one of claims 1-4, wherein the data channel comprises either:a BDC through which a bootstrap application runs to provide an entry to load various data channel applications; oran ADC through which a specific data channel application runs.12.The method of any one of claims 1-4, wherein the remote side comprises one of:the MF when establishing a BDC, ora terminating UE when establishing an ADC for peer-to-peer communication.13.The method of any one of claims 1-4, wherein:the second QUIC parameters represent a media endpoint of the MF, andthe SDP answer includes the second QUIC parameters containing an IP address and a UDP port of the MF for QUIC connection establishment.14.The method of any one of claims 1-4, wherein:the data channel comprises an ADC, andthe SDP offer includes ADC information and associated data channel (DC) application binding information that allows a terminating UE to determine whether to use a specific DC application for the ADC to be established between the UE and the terminating UE.15.The method of any one of claims 1-4, wherein:the data channel comprises an ADC, andthe first or second QUIC parameters include an MSID indicating a media stream for the ADC, the MSID comprising an indicator of a specific DC application.16.The method of any one of claims 1-4, wherein:the data channel comprises a BDC, andthe first or second QUIC parameters include an MSID indicating a media stream for the BDC.17.The method of claim 1, comprising: before sending the SDP offer for the data channel,indicating UE capability of DC over QUIC to the IMS network; andreceiving network capability indication of DC over QUIC from the IMS network.18.The method of claim 1, whereinthe data channel establishment is to establish a BDC; andestablishing the QUIC connection comprises establishing the QUIC connection towards the MF; andthe MF terminates the QUIC connection from the UE and sets up another QUIC connection towards a DCSF.19.The method of claim 1, comprising:after establishing the QUIC connection with the MF, establishing an ADC with a terminating UE through a separate SDP offer / answer exchange, wherein the ADC uses a second QUIC connection that is established directly between the UE and the terminating UE.20.A wireless communication apparatus comprising at least one processor configured to cause the wireless communication apparatus to implement a method of any one or more of claims 1-19.21.At least one computer-readable medium having code stored thereon, the code, upon execution by at least one processor of an apparatus, causing the apparatus to implement a method of any one or more of claims 1-19.