Method and apparatus for multiplexing internet protocol multimedia subsystem data channels

By using the SDP mechanism in the wireless communication system to negotiate data channel stream identifiers and attributes, the multiplexing problem of IMS data channel applications is solved, enabling efficient provision and access of data channel applications in real-time interactive services and improving the service quality of the communication system.

CN121128152APending Publication Date: 2025-12-12SAMSUNG ELECTRONICS CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202480033171.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2023-08-07
Filing Date
2024-05-16
Publication Date
2025-12-12

AI Technical Summary

Technical Problem

In the existing technology, the data channel multiplexing method between the server and user equipment (UE) of IMS data channel application has not been effectively implemented, resulting in the inefficiency of providing and accessing the data channel application for real-time interactive services.

Method used

By employing a Session Description Protocol (SDP) proposal and response mechanism in a wireless communication system, including data channel flow identifiers and related attributes, multiplexing and negotiation of data channels are achieved, ensuring the synchronization of data channel flow identifiers and attributes between network entities and user equipment.

Benefits of technology

It enables effective multiplexing of IMS data channels, supports efficient provision and access of data channel applications in real-time interactive services, and improves communication efficiency and service quality between user equipment and data channel servers.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121128152A_ABST
    Figure CN121128152A_ABST
Patent Text Reader

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. A method of a user equipment (UE) in a wireless communication system is provided, comprising: transmitting a first message including a session description protocol (SDP) proposal to a network entity; and receiving, from the network entity, a second message comprising an SDP reply corresponding to the SDP proposal, where the SDP proposal comprises a data channel flow identifier that directs the data channel and a first attribute related to data channel multiplexing, and where the SDP reply comprises access information of the network entity and the first attribute.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates generally to wireless communications, and more specifically to methods and apparatus for multiplexing Internet Protocol Multimedia Subsystem (IMS) data channels in wireless communication systems. Background Technology

[0002] 5G mobile communication technology defines a wide frequency band, enabling high transmission rates and new services. It can be implemented not only in "sub-6GHz" bands such as 3.5GHz, but also in "above 6GHz" bands, including 28GHz and 39GHz, known as millimeter waves (mmWave). Furthermore, 6G mobile communication technology (referred to as "super 5G systems") is being considered in terahertz bands (e.g., the 95GHz to 3THz band) to achieve transmission rates fifty times faster than 5G and ultra-low latency one-tenth that of 5G.

[0003] At the outset of 5G mobile communication technology development, in order to support services and meet performance requirements associated with enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), and massive machine-type communication (mMTC), ongoing standardization efforts were underway regarding the following: beamforming and massive MIMO for mitigating radio wave path loss and increasing radio wave transmission distance in mmWave; a set of supporting parameters for dynamic operation (e.g., operating multiple subcarrier spacings) for efficient utilization of mmWave resources and time slot formats; initial access technologies for supporting multi-beam transmission and broadband; the definition and operation of BWP (bandwidth portion); new channel coding methods (such as LDPC (low-density parity-check) codes for large-volume data transmission and polar codes for highly reliable transmission of control information); L2 preprocessing; and network slicing for providing dedicated networks for specific services.

[0004] Currently, given the services that 5G mobile communication technology is intended to support, discussions are underway regarding improvements and performance enhancements to the initial 5G mobile communication technology. Furthermore, physical layer standardization exists for technologies such as: V2X (Vehicle-to-Everything) for assisting autonomous vehicles in determining driving based on information transmitted by the vehicle regarding its location and status, and for enhancing user convenience; NR-U (New Radio Unlicensed) for system operation designed to comply with various regulatory requirements in unlicensed frequency bands; NR UE power saving; non-terrestrial networks (NTN) (which are UE-satellite direct communication used to provide coverage in areas where communication with terrestrial networks is unavailable); and positioning.

[0005] Furthermore, ongoing standardization exists in the air interface architecture / protocol for technologies such as: Industrial Internet of Things (IIoT) to support new services through interoperability and convergence with other industries; IAB (Integrated Access and Backhaul) for nodes to provide network service area extension by supporting wireless backhaul and access links in an integrated manner; mobility enhancements including conditional handover and DAPS (Dual Active Protocol Stack) handover; and two-step random access (2-step RACH for NR) to simplify the random access process. There is also ongoing standardization of 5G baseline architectures (e.g., service-based architectures or service-based interfaces) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, as well as system architectures / services for Mobile Edge Computing (MEC) to receive services based on UE location.

[0006] With the commercialization of 5G mobile communication systems, the already exponentially growing number of connected devices will connect to the communication network, and correspondingly, enhanced functionality and performance of 5G mobile communication systems, as well as the integrated operation of connected devices, are expected to be necessary. To this end, new research is planned related to extended reality (XR) for effectively supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality), 5G performance improvements and complexity reductions through the utilization of artificial intelligence (AI) and machine learning (ML), AI service support, metaverse service support, and drone communication.

[0007] Furthermore, this development of 5G mobile communication systems will serve as a foundation for developing not only new waveforms for providing coverage in the terahertz band of 6G mobile communication technology, such as full-dimensional MIMO (FD-MIMO), multi-antenna transmission technologies like array antennas and massive MIMO, metamaterial-based lenses and antennas for improving terahertz band signal coverage, high-dimensional spatial multiplexing technologies using OAM (orbital angular momentum) and RIS (reconfigurable smart surfaces), but also full-duplex technologies for improving the frequency efficiency of 6G mobile communication technology and enhancing system networks, AI-based communication technologies for system optimization by leveraging satellites and AI (artificial intelligence) from the design phase and internalizing end-to-end AI support capabilities, and next-generation distributed computing technologies for providing services at complexity levels exceeding the limitations of UE operational capabilities by utilizing ultra-high-performance communication and computing resources.

[0008] The telephone was first invented in the late 19th century, and mobile phones became popular in the late 20th century. With the development of mobile communication technology, video telephony services have been supported, allowing people to make calls while watching videos on the other end of the call. It is expected that 5G mobile communication systems will provide real-time interactive services at a new level, including touch and feel through talking to a remote other party.

[0009] The Internet Protocol (IP) Multimedia Subsystem (IMS) is a technology that provides multimedia services such as voice, audio, video, and data based on IP. IMS aims to improve the price competitiveness of services and radio services by using common Internet-based technologies and standardized network functions. IMS is independent of the access network and, due to improvements in session management functions, facilitates global interconnection between services and the conversion between wired and wireless networks through interoperability between applications on different networks. While IMS has been discussed for interaction and conversion between different mobile communication systems in Wide Code Division Multiple Access (W-CDMA) based on the initial all-IP network, IMS has expanded beyond mobile communication systems to support various integrated wired and wireless network technologies based on IP networks.

[0010] IMS supports the use of data channels that can deliver not only voice and images, but also random data streams within the same session. Depending on the purpose and characteristics of the data to be sent, the data channel can have transmission requirements such as latency, robustness, and bandwidth, and IMS operators can configure the data channel taking these requirements into account. Telephone services provided by operators can offer global user identification and contact based on phone numbers, user authentication, mobility, session control, Quality of Service (QoS), security, robustness, etc., and the use of data channels combined with telephone services achieves a combination of the advantages of telephone services and web technologies.

[0011] Web applications hosted on the Internet can be identified and retrieved using Hypertext Transfer Protocol Uniform Resource Locators (HTTP URLs). To enable multiple users to access services provided by the same web application, service access information such as URLs can be shared through methods not provided by the web application itself. Data channel applications using IMS data channels can be selected by the operator based on call context information such as user identifiers, and the selected data channel application is distributed to the UE by the data channel server via a dedicated data channel corresponding to the bootstrap data channel. The UE can send a root URL (" / ") request to the bootstrap data channel and download HTML web documents, JavaScript™, images, stylesheets, etc., included in the data channel application. To provide the various experiences desired by the service provider to participants in real-time interactive services, the UE needs to execute one or more data channel applications.

[0012] Therefore, there is a need in the art for a method and apparatus in which data channel applications can be provided through different data channel servers, and whereby a UE can effectively access one or more data channel servers. Summary of the Invention

[0013] This disclosure addresses at least the aforementioned problems and / or disadvantages, and provides at least the following advantages.

[0014] Therefore, one aspect of this disclosure is to provide a method for multiplexing IMS data channels in a wireless communication system.

[0015] One aspect of this disclosure is to provide an apparatus and method for establishing multiplexed data channels in a wireless communication system.

[0016] One aspect of this disclosure is to provide a method and apparatus for implementing real-time interactive services by providing participants in a real-time communication service with data channel applications provided from one or more data channel servers.

[0017] According to one aspect of this disclosure, a method for a UE in a wireless communication system includes sending a first message including a Session Description Protocol (SDP) offer to a network entity, and receiving a second message from the network entity including an SDP response corresponding to the SDP offer, wherein the SDP offer includes a data channel flow identifier of at least one bootstrap data channel and a first attribute related to data channel multiplexing, and wherein the SDP response includes access information of the network entity and the first attribute.

[0018] According to one aspect of this disclosure, a method of a network entity in a wireless communication system includes receiving a first message from a UE including an SDP proposal and sending a second message to the UE including an SDP response corresponding to the SDP proposal, wherein the SDP proposal includes at least one data channel flow identifier for guiding a data channel and a first attribute related to data channel multiplexing, and wherein the SDP response includes access information of the network entity and the first attribute.

[0019] According to one aspect of this disclosure, a UE in a wireless communication system includes a transceiver and at least one processor connected to the transceiver and configured to send a first message including an SDP proposal to a network entity via the transceiver and to receive a second message including an SDP response corresponding to the SDP proposal from the network entity, wherein the SDP proposal includes at least one data channel flow identifier for guiding a data channel and a first attribute related to data channel multiplexing, and wherein the SDP response includes access information of the network entity and the first attribute.

[0020] According to one aspect of this disclosure, a network entity in a wireless communication system includes a transceiver and at least one processor connected to the transceiver and configured to receive a first message including a Session Description Protocol (SDP) proposal from a UE via the transceiver, and to send a second message to the UE including an SDP response corresponding to the SDP proposal, wherein the SDP proposal includes at least one data channel flow identifier for guiding a data channel and a first attribute related to data channel multiplexing, and wherein the SDP response includes access information of the network entity and the first attribute. Attached Figure Description

[0021] The above and other aspects, features and advantages of embodiments of the present disclosure will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, wherein:

[0022] Figure 1 The structure provided by the web application according to an embodiment is shown;

[0023] Figure 2 An IMS network structure according to an embodiment is shown;

[0024] Figure 3 The interaction between IMS and the 5G core network (5GC) according to an embodiment is illustrated;

[0025] Figure 4 The Session Initiation Protocol (SIP) operation process in a mobile communication system according to an embodiment is illustrated;

[0026] Figure 5 The SDP negotiation process for a real-time interactive service in a communication system according to an embodiment is illustrated.

[0027] Figure 6 A network structure supporting data channel functionality in a communication system according to an embodiment is shown;

[0028] Figure 7 A UE protocol stack supporting data channel applications in a communication system according to an embodiment is shown;

[0029] Figure 8 The diagram illustrates a media plane structure in a communication system according to an embodiment, including a pilot data channel provided by two DCMFs;

[0030] Figure 9 A media plane structure in a communication system according to an embodiment is shown, in which pilot data channels provided by two DCMFs are multiplexed;

[0031] Figure 10 The process of establishing a multiplexed guided data channel in a communication system according to an embodiment is illustrated;

[0032] Figure 11 The diagram illustrates a media plane structure provided by two DCMFs supporting guided data channel multiplexing in a communication system according to an embodiment;

[0033] Figure 12 The process of establishing two multiplexed boot data channels in a communication system according to an embodiment is illustrated;

[0034] Figure 13 A media plane structure in a communication system according to an embodiment is shown, wherein a boot data channel and an application data channel are multiplexed.

[0035] Figure 14 The process of establishing and guiding data channel multiplexing in a communication system according to an embodiment is illustrated;

[0036] Figure 15 The media plane structure of an application data channel supporting multiplexing toward different endpoints (ATDE) in a communication system according to an embodiment is shown;

[0037] Figure 16 The process of establishing an application data channel and exchanging data in a communication system according to an embodiment, where ATDE multiplexing is applied, is illustrated.

[0038] Figure 17a and Figure 17b The invention illustrates whether an indication in a communication system according to an embodiment supports negotiation using ATDE multiplexing with SDP.

[0039] Figure 18 The internal structure of a network entity in a wireless communication system according to an embodiment is shown; and

[0040] Figure 19 The internal structure of a UE in a wireless communication system according to an embodiment is shown. Detailed Implementation

[0041] The following description, provided with reference to the accompanying drawings, is intended to aid in a comprehensive understanding of embodiments of the present disclosure. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. For clarity and brevity, descriptions of well-known functions and structures may be omitted.

[0042] In the accompanying drawings, some elements may be exaggerated, omitted, or shown schematically.

[0043] According to the detailed embodiments presented, the elements included in this disclosure are represented in a singular or plural form. However, for the sake of convenience of description, the singular or plural form has been suitably chosen as presented, and this disclosure is not limited to elements expressed in a singular or plural form. Thus, an element represented in a plural form may also include a single element, or an element represented in a singular form may include multiple elements.

[0044] In the accompanying drawings, similar reference numerals may be used to denote similar or related elements. It should be understood that the singular form of a noun corresponding to an item may include one or more items unless the relevant context clearly indicates otherwise. As used herein, each of phrases such as “A or B,” “at least one of A and B,” “at least one of A or B,” “at least one of A, B, or C,” “at least one of A, B, and C,” and “at least one of A, B, or C” may include all possible combinations of items listed together in a corresponding phrase. Terms such as “first,” “second,” “first,” and “second” as used herein may be used to distinguish corresponding elements from other elements and do not limit the importance or order of elements. If a first element is referred to as “coupled / connected to another element (e.g., a second element)” with or without the terms “operably” or “communicably,” this indicates that the first element may be coupled / connected to the second element directly (e.g., wired), wirelessly, or via a third element.

[0045] In this document, a base station (BS) is an entity that allocates resources to terminals and can be at least one of a gNode B, eNode B, Node B, radio access unit, base station controller, and node on a network. Terminals can include UEs, mobile stations (MS), cellular phones, smartphones, computers, or multimedia systems capable of performing communication functions. While 5G NR or 5G NR systems are described herein by way of example, embodiments of this disclosure can also be applied to other communication systems with similar technical backgrounds or channel types. Based on the assessment of those skilled in the art, this disclosure can be applied to other communication systems with modifications without explicitly departing from its scope.

[0046] This disclosure relates to methods and apparatus for providing data channel applications in communication systems that provide real-time interactive services.

[0047] Figure 1 An example of a web application providing a structure according to an embodiment is shown.

[0048] refer to Figure 1User 100 can consume web applications using UE 110. A web browser 111 running on user device 110 can perform the rendering functions of the web application. For example, web browser 111 can receive data input from user 100, present the results of user data processing to a display device, and provide the results to user 100. The information used for web application rendering by web browser 111 may include Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript™, and can be downloaded from web application server 120 via a request using a Hypertext Transfer Protocol (HTTP) Uniform Resource Locator (URL). HTML provides the format of the web application, CSS controls the display of the web application shown to the user, and the programming language JavaScript™ provides tools for changing the operation of various components included in the web application.

[0049] User data processing can be a process in which a web browser 111 sends a data processing request to a web application server 120 and receives a response to the data processing from the web application server 120. The web application server 120 may include application logic 121 for processing user data, a file management system 122, and a database 123.

[0050] Figure 2 An IMS network structure according to an embodiment is shown.

[0051] refer to Figure 2 UE 210 can communicate with another UE located in the remote IMS network 280 and the IM CN subsystem via the IP Multimedia Core Network (IM CN) ​​subsystem. The IM CN subsystem may include P-CSCF 220, S-CSCF 230, IMS AS 240, HSS 250, IMS AGW 260 and / or MRF 270, and these components can perform the following functions.

[0052] Proxy Call Session Control Function (P-CSCF) 220: The P-CSCF can perform the first contact point function, through which the UE can access the IMS.

[0053] Service CSCF (S-CSCF) 230: S-CSCF can handle the real user session state of the network.

[0054] IMS Application Server (AS) 240: The IMS AS can provide and execute Internet Multimedia (IM) value-added services. IMSAS can influence SIP sessions by acting as a proxy for services supported in the carrier network.

[0055] Home Subscriber Server (HSS) 250: The HSS can act as a database for storing user information.

[0056] IMS Access Gateway (AGW) 260: The IMS-AGW can be located on the media transport path to manage the network addresses associated with inbound and outbound media streams.

[0057] Media Resource Function (MRF) 270: The MRF can perform various processing tasks related to media streams. The MRF can be divided into the Multimedia Resource Function Controller (MRFC) which performs control and the Multimedia Resource Function Processor (MRFP) which performs media processing.

[0058] Inquiry / Service CSCF (I-CSCF) 230: The I-CSCF can perform contact point functions for network operator subscribers or roaming users currently located within the network operator's service area.

[0059] refer to Figure 2 The interface between components can be represented by the following reference points.

[0060] Gm: Reference point Gm enables communication between the UE and the IM CN subsystem. For example, the UE can request network registration and session control through reference point Gm. SIP, as described below, can be used for reference point Gm.

[0061] Mw: Reference point Mw can support the exchange and transmission of signaling messages between CSCFs.

[0062] ISC: Reference Point ISC can support the information exchange required for services provided by the CSCF and service platform (e.g., IMS AS).

[0063] Sh: Reference point Sh can support the information exchange required for services provided by the service platform between the HSS and the service platform (e.g., IMS AS).

[0064] Cx: Reference point Cx can support information transmission between HSS and CSCF.

[0065] Mr' / Cr: Reference point Mr' can support session control interaction between IMS AS and MRFC, and reference point Cr can support media control interaction between IMS AS and MRFC.

[0066] Iq: Reference point Iq enables the exchange of information required to allocate and release transport addresses between P-CSCF and IMS AGW.

[0067] Mb: Reference point Mb can support IMS media transmission between IMS components.

[0068] The UE and IMS network can exchange features and capabilities to support services during registration or session establishment. For example, the UE can indicate that it supports data channels by using a media feature tag with the value "webrtc-datachannel" + sip.app-subtype.

[0069] The wireless communication system described in this paper can be 5GS. A 5G system can include a 5G radio access network (Next Generation Radio Access Network (NG-RAN)) and 5GC. 5GS can interoperate with existing LTE and can connect to non-3GPP radio access technologies such as Wi-Fi. 5GC can operate between NG-RAN and external packet data networks (Public Data Network (PDN)) and can provide users with various types of data services, including voice. The elements of the 5GC's control plane can be considered as Virtualized Network Functions (VNFs), and communication between VNFs can be considered as one VNF providing services to other VNFs through the exchange of RESTful application programming interfaces (APIs). The API-based communication interface between VNFs is called a Service-Based Interface (SBI).

[0070] Figure 3 An example of the interaction between IMS and 5GC according to an embodiment is shown.

[0071] refer to Figure 3 The SBI-enabled P-CSCF 320 can communicate with the Policy Control Function (PCF) 330, which can be designated as reference point N5. The PCF 330 can support the creation and distribution of policies for managing network operations, and the SBI-enabled P-CSCF 320 can be considered as an Application Function (AF) providing services to another VNF using the PCF 330.

[0072] The SBI-enabled HSS 360 can communicate with the SBI-enabled I / S-CSCF 340 via reference point N70, and with the SBI-enabled IMS AS 350 via reference point N71. Similarly, the SBI-enabled I / S-CSCF 340 and the SBI-enabled IMS AS 350 can be considered as AFs using services provided by the SBI-enabled HSS 360, and the functions provided to reference points N70 and N71 can be equivalent to the functions provided to reference points Cx and Sh, respectively.

[0073] SIP is an application-layer signaling protocol that defines a process in which intelligent UEs wishing to communicate over the Internet identify each other, locate themselves, and create or delete / modify multimedia communication sessions between each other. SIP is a request / response format that controls the creation, modification, and termination of multimedia service sessions such as Internet-based conferencing, telephone, voicemail, event notifications, and instant messaging, and can be used with all TCP and User Datagram Protocol (UDP) protocols. It distinguishes individual users using SIP URLs, similar to email addresses, providing services without relying on IP addresses. Because SIP is based on text developed using many parts of HTTP and SMTP, it is seamlessly implemented and possesses the flexibility and scalability to generate a wide variety of services by combining with many other protocols used on the Internet.

[0074] Figure 4 The SIP operation process in a mobile communication system according to an embodiment is illustrated.

[0075] refer to Figure 4 User Alice communicates with Bob's UE (SIP UE) 440 using her own UE (SIP UI) 410, and the following communication procedures can be performed between Alice's SIP proxy server 420 and user Bob's SIP proxy server 430 to establish a communication session.

[0076] In step 411, Alice's UE 410 sends a SIP INVITE request to Alice's proxy server 420, which includes the following SDP proposal. The SIP INVITE may include the caller's (Alice's) SIP URI, the receiver's (Bob's) SIP URI, and information for establishing a communication session.

[0077] In step 413, Alice's proxy server 420 receives the SIPSIP INVITE request sent in step 411 and sends a 100 Trying response to Alice's UE 410. The 100 Trying response indicates that the INVITE has been received and that Alice's proxy server 420 is operating to forward the INVITE request to the recipient (Bob).

[0078] In step 415, Alice's proxy server 420 identifies the network address of Bob's proxy server 430 using a method such as Domain Name Service (DNS) and sends a SIP INVITE to Bob's proxy server 430. Alice's proxy server 420 can add the network address of Alice's proxy server 420 to the Via header field of the SIP INVITE that will be sent to Bob's proxy server 430.

[0079] In step 417, Bob's proxy server 430 receives the SIP INVITE and sends 100 Trying to Alice's proxy server 420 to indicate that Bob's proxy server 430 has received the SIP INVITE and is processing the request.

[0080] In step 419, Bob's proxy server 430 identifies the network address of Bob's UE 440 using a database and sends a SIP INVITE to Bob's UE 440. Bob's proxy server 430 can then add its own network address to the Via header field of the SIP INVITE to be sent to Bob's UE 440.

[0081] In step 421, Bob's UE 440 receives an INVITE and notifies Bob of a call request received from Alice via sound, vibration, and screen notification. Bob's UE 440 notifies Bob's proxy server 430 that an operation is being performed via a 180 Ringing response. The network address of Bob's proxy server 430 can be detected using the information added to the Via header field in step 419.

[0082] In step 423, Bob's proxy server 430 forwards the received 180 Ringing response to Alice's proxy server 420. The network address of Alice's proxy server 430 can be detected by the information added to the Via header field in step 415.

[0083] In step 425, Alice's proxy server 420 transmits the received 180 Ringing response to Alice's UE 410. Alice's UE 410, which receives the 180 Ringing response, can notify Alice of the receipt via a ringback tone.

[0084] In step 427, when Bob determines that the call has been accepted, Bob's UE 440 notifies Bob's proxy server 430 that the call has been accepted via a 200 OK response including the SDP response described below. As a result, SDP is transmitted from Alice's UE 410 to Bob's UE 440, and then again from Bob's UE 440 to Alice's UE 410, corresponding to the negotiation of media capabilities using SDP provide / respond. The 200 OK response may include a network address in the Contact header field that allows direct communication with Bob's UE 440.

[0085] In step 429, Bob's proxy server 430 forwards the received 200 OK response to Alice's proxy server 420. The network address of Alice's proxy server 430 can be detected using the information added to the Via header field in step 415.

[0086] In step 431, Alice's proxy server 420 transmits the received 200 OK response to Alice's UE 410. Upon receiving the 200 OK response, Alice's UE 410 can stop the ringing tone and notify Alice that the call has been accepted.

[0087] In step 433, Alice's UE 410 sends an ACK message to Bob's UE 440, notifying that the final response (200 OK) has been received. The ACK message can be sent to Bob's UE 440 without going through Alice's proxy server 420 and Bob's proxy server 430, by using the network address of Bob's UE 440 included in the Contact header field in step 427.

[0088] In step 435, the handshake process including INVITE / 200 / ACK has been completed, and the media session begins. Alice or Bob can change the characteristics of the media session during the session, which can be done through a re-INVITE / 200 / ACK handshake that includes an SDP proposal reflecting the changed characteristics of the media session.

[0089] In step 437, when Bob ends the call first, Bob's UE 440 sends a BYE message to Alice's UE 410.

[0090] In step 439, Alice's UE, which received the BYE message, sends a 200 OK response to Bob's UE 440 to notify that the BYE message has been received and to end the communication session.

[0091] exist Figure 4The SIP INVITE request sent by Alice's UE 410 in step 411 may include feature and capability information to support the service. Figure 4 In step 413, Alice's proxy server 420 can determine whether to support the features and capabilities included in the SIP INVITE request based on Alice's subscription information and the network provider's policies, and remove some features and capabilities, then send these features and capabilities to Bob's proxy server 430, or refuse to establish a call session based on the determination result. Figure 4 In step 417, Bob's proxy server 420 may, based on Bob's subscription information and the network provider's policies, respond to the SIP INVITE request received from Alice's proxy server 420 to determine whether the requested features and capabilities are supported, and delete some features and capabilities, and then send these features and capabilities to Bob's UE 440, or refuse to establish a call session based on the determination result.

[0092] Figure 4 The SDP included in the SIP message in steps 411 and 427 is described as an example. SDP is a protocol based on the American Standard Code for Information Interchange (ASCII) strings used to describe multimedia sessions and associated scheduling information. SDP sends information about the media stream in a multimedia session to join the session, and a multimedia session is defined as a media stream of a duration, which does not necessarily have to be continuous. Multicast-based sessions on the Internet aim to notify the existence and duration of a session and send session participation information, which is the goal in a unicast environment. SDP message content may include the session name and goal, session progress time, session configuration media, media reception information, etc.

[0093] An SDP description is a document format and may include a session-level section followed by zero or more media descriptions. Examples of SDP descriptions are shown in Table 1 below.

[0094] Table 1

[0095]

[0096] In Table 1, the SDP description includes a session-level section and two media descriptions ("m="line"). The session-level section includes "v="line", "o="line", "s="line", "s="line", and "t="line". The meaning of each line in the SDP description is explained below.

[0097] - "v=" row (version field): The row that indicates the SDP version. The row with "v=" in Table 1 indicates that the SDP version is 0.

[0098] "o=" row (initiator field): The row indicating the initiator. The "o=" row can sequentially include Username, Session Identifier (sess-id), Session Version (sess-version), Network Type (nettype), Network Address Type (addtype), and the network address (unicast address) of the device initiating the session. The "o=" row in Table 1 above instructs Alice to initiate a session with identifier 2819384758 and version 2819384758 in an Internet (IN) network with IP4 address 198.51.100.1.

[0099] "s=" line (session name line): Indicates a line containing the session name in letters. The "s=" line in Table 1 above indicates that the session name is "Calling Bob".

[0100] The "c=" line (connection field): Information required to establish a network connection. The "c=" line can include the network type (nettype), network address type (addtype), and network address (connection address) in sequence. The "c=" line in Table 1 above indicates the establishment of a network connection to an IN network with the IP4 address 198.51.100.1. When establishing a media session with another IP address, the "c=" line ("m=" line) can be configured in units of media description.

[0101] The "t=" row (time field) indicates the start and end times of the session. The "t=" row in Table 1 above indicates a permanent session.

[0102] "m=" line (media field): A media description can begin with a "m=" line and end with the next "m=" line or the last of the SDP description, and can include additional attributes. The "m=" line can include, in sequence, media type (media), port number (port), transport protocol identifier (proto), and media format technology (fmt). In Table 1 above, the first "m=" line indicates that audio information is sent to the RTP / AVP protocol via port 49170, and the media format (0) is displayed as an additional attribute; the second "m=" line indicates that video information is sent to the RTP / AVP protocol via port 51372, and the media format (99) is displayed as an additional attribute. RTP / AVP is the audio / video profile of the Real-Time Transport Protocol (RTP).

[0103] In order to provide a real-time interactive service in a communication system according to various embodiments of the present disclosure, UEs of users participating in the service should negotiate a media session included in the service. The communication system described herein can reach an agreement on the media session through SDP negotiation to provide the service (e.g., a real-time interactive service). Hereinafter, it is assumed that the service provided in the communication system is a real-time interactive service, but the present disclosure is not limited thereto.

[0104] Figure 5 The SDP negotiation process for real-time interactive services in a communication system according to an embodiment is illustrated.

[0105] exist Figure 5 Note that this only considers the SDP switching process and does not include the SIP operations mentioned above.

[0106] refer to Figure 5 The SDP negotiation for real-time interactive services in the communication system described in this paper can be performed according to the following process.

[0107] In step 511, Alice's UE 510 sends an SDP proposal to Bob's UE 520. Table 2 below shows an example of an SDP proposal. Referring to Table 2, Alice proposes media descriptions for three media streams.

[0108] Audio stream 1: UDP port 49170, G.711 ulaw codec (G.711)

[0109] Video Stream 1: UDP port 51372, H.261 codec (payload type 31)

[0110] Video stream 2: UDP port 53000, MPEG codec (payload type 32)

[0111] Table 2

[0112]

[0113] In step 513, Bob's UE 520 generates a response to the SDP proposal (SDP response) and sends the SDP response to Alice's UE 510. Table 3 below shows an example of an SDP response. Referring to Table 3, Bob allows media descriptions for three media streams.

[0114] Audio stream 1: UDP port 49920, G.711 ulaw codec (G.711)

[0115] Video Stream 1: No need to use H.261 codec to open the video stream (UDP port configured as 0, and no media attributes defined (" a=" line))

[0116] Video stream 2: UDP port 53000, MPEG codec (payload type 32)

[0117] Table 3

[0118]

[0119] In step 515, Bob's UE 520 changes the UDP port number for receiving voice from 49920 to 65422 during the communication session and adds a separate voice stream dedicated to receiving events. Bob's UE 520 generates an SDP proposal reflecting the content and sends the SDP proposal to Alice's UE 510. Table 4 below shows an example of an SDP proposal. Referring to Table 4, Bob proposes media descriptions for four media streams.

[0120] Voice stream 1: Change UDP port 49920 to 65422, G.711 ulaw codec (G.711)

[0121] Video Stream 1: No need to use H.261 codec to open the video stream (UDP port configured as 0, and no media attributes defined (" a=" line))

[0122] Video stream 2: UDP port 53000, MPEG codec (payload type 32)

[0123] Voice stream 2: UDP port 51434, DTMF event (payload type 110), dedicated to receiving (receive only).

[0124] Table 4

[0125]

[0126] In step 517: Alice's UE 510 generates a response to the SDP proposal and sends the SDP response to Bob's UE 520. Table 5 below shows an example of an SDP response. Referring to Table 5, Alice allows media descriptions for four media streams.

[0127] Audio stream 1: UDP port 49170, G.711 ulaw codec (G.711)

[0128] Video Stream 1: Open the video stream without using the H.261 codec (configure the UDP port to 0).

[0129] Video stream 2: UDP port 53000, MPEG codec (payload type 32)

[0130] Voice stream 2: UDP port 53122, DTMF event (payload type 110), dedicated to transmission (transmit only).

[0131] Table 5

[0132]

[0133] The web applications described herein for providing services (e.g., real-time interactive services) in a communication system can be provided from a Data Channel Application Server (DCAS). The Data Channel Application Server can reside in an IMS operator network or a third-party network. The web applications provided by the Data Channel Application Server can be referred to as Data Channel Applications (DCAs). UEs participating in services provided by Data Channel Applications (e.g., real-time interactive services) can exchange the data required for the service with other UEs participating in the same service directly or via intermediate nodes through the Data Channel (DC), and can communicate with the Data Channel Application Server using the Bootstrap Data Channel (BDC).

[0134] Figure 6 A network structure supporting data channel functionality in a communication system according to an embodiment is shown.

[0135] refer to Figure 6 The communication system may include a UE 610 and an IM CN subsystem supporting data channel functionality. The UE 610 can communicate with another UE located in a remote IMS network 680 and components of the IM CN subsystem via the IM CN subsystem. The IM CN subsystem may include a PCSCF 620, an SCSCF 630, an IMS AS 640, an HSS 650, an IMS AGW 660, and / or a data channel server 670. Figure 6 The descriptions of UE 610, P-CSCF 620, I / S-CSCF 630, IMSAS 640, HSS 650, and IMS AGW 660 in the communication system are referenced to the descriptions of UE 210 or 310, P-CSCF 220 or 320, I / S-CSCF 230 or 340, IMS AS 240 or 350, HSS 250 or 360, and IMS AGW 260 or Figure 2 Or the description of MRF 270 in 3, and overlapping descriptions may be omitted.

[0136] The data channel server 670 may include a data channel signaling function (DCSF) 671, a data channel application library (DCAR) 672, a data channel media function (DCMF) 673 and / or an MRF 674.

[0137] Data channel signaling function 671 can manage and control the data channel, including the data channel bootstrapping function.

[0138] Manage data channels and generate / receive events via communication with the IMS AS.

[0139] Manage data channel applications and control distribution.

[0140] It communicates with 5G network function 690 to provide data channel application services.

[0141] Used as a proxy for distributing resources of application server 691 for data channels.

[0142] The data channel application (app) repository 672 can store and manage data channel applications and can be located inside or outside the data channel server 670.

[0143] Data channel media function 673 and MRF 674 can manage and control the media resources to be transmitted to the data channel, which includes the bootstrap data channel, and

[0144] Used as a proxy to exchange data with one endpoint of the data channel connected to the UE and another endpoint.

[0145] Data Channel Media Function 673 and MRF 374 can provide the same functionality through different interfaces, and considering compatibility with other network devices and UEs, operators can include only one or both of Data Channel Media Function 673 and MRF 674 in Data Channel Server 670.

[0146] Figure 7 A UE protocol stack supporting data channel applications in a communication system is illustrated according to an embodiment.

[0147] refer to Figure 7The data stream / bearer / QoS layer 710 can support packet processing rules conforming to relevant standards. The SIP / SDP layer 720 can use SIP / SDP to negotiate media parameters and control the session. Media data such as video, voice, still images, and text can be encoded by the codec layer 730 and sent as packets via RTP 740, and the RTP control protocol (RTCP) 740 can be used to control the RTP session and report the receiving environment. The Datagram Transport Layer Security (DTLS) layer 750 can initiate the establishment of a DTLS session between the UE and the IMS network or between the UE, and the DTLS session can provide security for Stream Control Transport Protocol (SCTP) data transmission. The SCTP layer 760 can initiate the establishment of a transport session, including SCTP associations between the UE and the IMS network or between the UE. An SCTP association can include one or more data channels, and each data channel can be identified by a flow ID provided by SCTP. The data channel layer 770 can perform integrated management of the DTLS layer 750 and SCTP layer 760, and data channel applications can establish data channels and provide a JavaScript™ API that enables the exchange of application data using the established data channel. The InCallUI layer 780 can manage the UE's display and input devices during a call, and DCUI refers to the UE's support for data channel functionality. For example, in the case of an Android system, HTML content included in a data channel application can be displayed on the screen via the local web engine WebView, and JavaScript™ code can be executed. The DCUI can interact with the data channel server through the API provided by the data channel layer 770 to obtain data channel applications by bootstrapping data channels and establish additional data channels for data channel applications.

[0148] In this document, a UE can obtain a data channel application from one or more data channel application providers. The data channel stream ID that guides the data channel can be mapped to a data channel application provider. For example, data channel stream ID "0" can be mapped to the network provider where the UE is registered (e.g., a local network provider), data channel stream ID "10" can be mapped to a subscriber of the network provider where the UE is registered (e.g., a local user as a local network user), data channel stream ID "100" can be mapped to a remote network provider (e.g., IMS 680), and data channel stream ID "110" can be mapped to a subscriber of a remote network provider (e.g., a remote user as a remote network user). This mapping can be described on a UE-by-UE basis.

[0149] In this paper, the UE can obtain data channel applications through one or more DCMFs.

[0150] Figure 8 A media plane structure comprising a pilot data channel provided by two DCMFs is shown in a communication system according to an embodiment.

[0151] refer to Figure 8 The first DCMF (DCMF #1) 813, located in network A 810, can provide HTTP proxy functionality for the first DSCF (DSCF #1) 812. DCMF #1 813 can provide two bootstrap data channels to the first UE (UE #1) 811 and the second UE (UE #2) 821, where the data channel application providers are the network A 810 provider and the network A 810 subscriber. Since DCMF #1 813 and the first UE 811 are located in network A 810, the flow ID for obtaining the bootstrap data channel for the data channel application provided by the network A 810 provider can be configured to "0", and the flow ID for obtaining the bootstrap data channel for the data channel application provided by the network A subscriber can be configured to "10". However, from the perspective of the second UE 821 located in network B 820, network A 810, where DCMF #1 813 is located, corresponds to a remote network. Therefore, the flow ID used to obtain the pilot data channel for the data channel application provided by the network A 810 provider can be configured as "100", and the flow ID used to obtain the pilot data channel for the data channel application provided by the network A subscriber can be configured as "110".

[0152] Similarly, a second DCMF (DCMF #2) 823 located in network B 820, which is different from network A 810, can provide HTTP proxy functionality for the second DCSF (DCSF #2) 822 and provide two bootstrap data channels to UE #1 811 and UE #2 821, where the data channel application providers are the network B 820 provider and the network B subscriber. Since DCMF #2 823 and UE #2 821 are located in network B 820, the flow ID for obtaining the bootstrap data channel application provided by the network B 820 provider can be configured to "0", and the flow ID for obtaining the bootstrap data channel application provided by the network B 820 subscriber can be configured to "10". However, from the perspective of the first UE 811 located in network A 810, network B 820, where DCMF #2 823 is located, corresponds to a remote network. Therefore, the flow ID of the pilot data channel provided by the network B 820 provider for obtaining data channel applications can be configured as "100", and the flow ID of the pilot data channel provided by the network B subscriber for obtaining data channel applications can be configured as "110".

[0153] refer to Figure 8 DCMF #1 813 and DCMF #2 823 can be considered as separate devices located in network A 810 and network B 820. In this case, UE #1 811 (or UE #2 821) should be configured with DTLS sessions for communicating with DCMF #1 813 and DTLS sessions for communicating with DCMF #2 823, respectively. Since the SDP media description ("m=" line) can include information for configuring a DTLS session, the DTLS session configuration information for communicating with DCMF #1 813 can be negotiated as a first media description (first "m=" line), and the DTLS session configuration information for communicating with DCMF #2 823 can be negotiated as a second description (second "m=" line).

[0154] In the communication system described in this paper, the DCMF can support guided data channel multiplexing. A DCMF supporting guided data channel multiplexing can provide the UE with connectivity to one or more DCMFs by using a DTLS session and a DTLS anchoring function for communication with another DCMF.

[0155] Figure 9 The diagram illustrates a media plane structure in a communication system according to an embodiment, in which pilot data channels provided by two DCMFs are multiplexed. Figure 9 An example is shown where only one of the two DCMFs supports pilot data channel multiplexing.

[0156] refer to Figure 9 The first UE (UE #1) 911 and the first DCMF (DCMF #1) 913 can connect via a first DTLS session, and the first DTLS session can include four bootstrap data channels with flow ID values ​​“0”, “10”, “100”, and “110”. DCMF #1 913 can perform HTTP proxy functions for the first DCSF (DCSF #1) 912, and for this purpose, it can use two bootstrap data channels with flow ID values ​​“0” and “10” connected to the first DTLS session of UE #1 911, and two bootstrap data channels with flow ID values ​​“100” and “110” connected to the second DTLS session of the second UE (UE #2) 921.

[0157] DCMF #1 913 can provide SCTP association functionality between DCMF #2 923 and UE #1 911, and DCMF #2 923 performs HTTP proxy functionality for the second DCSF (DCSF #2) 922. To provide SCTP association functionality, DCMF #1 913 and the second DCMF (DCMF #2) 923 can connect via a third DTLS connection.

[0158] Figure 10 The multiplexing bootstrapping data channel establishment process in a communication system according to an embodiment is illustrated. Figure 10 In the above, it is assumed that the first UE (UE #1) 1010, the first P / S / I-CSCF (P / S / I-CSCF #1) 1020, the first IMS AS (IMSAS #1) 1030, and the first DCMF (DCMF #1) 1040 are located in the first network, and the second P / S / I-CSCF (P / S / I-CSCF #2) 1050, the second IMS AS (IMS AS #2) 1060, the second DCMF (DCMF #2) 1070, and the second UE (UE #2) 1080 are located in the second network, which is different from the first network.

[0159] refer to Figure 10 The UE can establish a multiplexed boot data channel and obtain data channel applications through the following process.

[0160] In step 1011, UE #1 1010 sends a SIP INVITE request message including an SDP proposal to IMS AS #1 1030 via P / S / I-CSCF #1 1020. For example, the SDP proposal may include a first bootstrap data channel media description (m-line #1) for bootstrap data channel establishment, as shown in Table 6 below. Among the attributes included in Table 6, the row with "b=" (bandwidth field) represents the bandwidth of the data channel. The attributes "a=max-message-size:", "a=sctp-port:", "a=setup:", "a=fingerprint:", and "a=tls-id" are attributes used to configure the User Datagram Protocol (UDP) / Datagram Transport Layer Security (DTLS) / System Control Transport Protocol (SCTP). The attribute "a=dcmap:" is an attribute used to configure data channel-related parameters and may include the data channel stream ID (dcmap-stream-id) and the application layer protocol (sub-protocol) to be sent to the data channel. The data channel stream ID for the pilot data channel can be mapped to a data channel application provisioning entity. The media descriptions in Table 6 can provide all four data channel application provisioning entities. Specifically, data channel stream IDs "0" and "10" are requests for establishing a pilot data channel with DCMF #1 1040, and data channel stream IDs "100" and "110" are requests for establishing a pilot data channel with DCMF #2 1070. UEs participating in the real-time interaction service can also include the attribute "a=bdcmultiplexing:" in the SDP proposal used for pilot data channel establishment. The attribute "a=bdcmultiplexing:" is an attribute indicating whether pilot data channel multiplexing is supported, and can have a value "yes" as its parameter. The value "yes" can indicate that the UE or network device sending the SDP including the media description supports pilot data channel multiplexing. Based on the attribute "a=bdcmultiplexing", UE #1 1010 can notify the first network whether pilot data channel multiplexing is supported and identify whether the first network supports pilot data channel multiplexing. During the registration process of UE #1 1010 in the IMS network or the call session establishment process, the support for bootstrapping data channel multiplexing can be exchanged via SIP messages or separate protocols. For example, a signal notification can be sent using a SIP message's capability indicator or media feature tag.

[0161] Table 6

[0162]

[0163] In step 1013, the IMS AS #1 1030 receiving the SIP INVITE request message analyzes the pilot data channel media description in the SDP proposal and allocates the resources of the pilot data channel to the DCMF #1 1040. The IMS AS #1 1030 may obtain the information required for resource allocation from at least one of the HSS and DCSF, and the information required for resource allocation may include information indicating whether the DCMF #1 1040 supports pilot data channel multiplexing.

[0164] In step 1015, IMS AS #1 1030 modifies the SDP proposal and sends a SIP INVITE request message containing the same content to P / S / I-CSCF #1 1020. The modified SDP proposal may include the result of operator policy or resource allocation of DCMF #1 1040. In this document, IMS AS #1 1030 may remove the first bootstrap data channel media description (m-line #1) from the SDP proposal and add a second bootstrap data channel media description (m-line #2) and a third bootstrap data channel media description (m-line #3). The second bootstrap data channel media description (m-line #2) may include access information from DCMF #1 1040 as a proposal to establish a bootstrap data channel between DCMF #1 1040 and UE #2 1080. The third bootstrap data channel media description (m-line #3) may be a proposal to provide UE #1 1010 with SCTP association functionality with DCMF #2 1070.

[0165] When DCMF #1 1040 does not support pilot data channel multiplexing, IMS AS #1 1030 can reject the pilot data channel establishment request.

[0166] In step 1017, P / S / I-CSCF #1 1020 identifies the second network that UE #2 1080 has subscribed to and searches P / S / I-CSCF #2 1050 to send a SIP INVITE request message that includes a modified SDP proposal.

[0167] In step 1019, a SIP INVITE request message including the modified SDP proposal sent by P / S / I-CSCF #1 1020 is sent to IMS AS #2 1060 via P / S / I-CSCF #1 1050.

[0168] In step 1021, the IMS AS #2 1060, which receives the SIP INVITE request message, analyzes the pilot data channel media description in the modified SDP proposal and allocates pilot data channel resources to DCMF #2 1070. IMS AS #2 1060 can obtain the information required for resource allocation from at least one of the HSS and DCSF, and the information required for resource allocation may include information indicating whether DCMF #2 1070 supports pilot data channel multiplexing. Figure 10 In this context, it is assumed that at least one of DCMF #21070 and UE #2 1080 does not support data channel multiplexing.

[0169] In step 1023, IMS AS #2 1060 modifies the SDP proposal and sends a SIP INVITE request message including the modified SDP proposal to P / S / I-CSCF #2 1050. The modified SDP proposal may include operator policies or resource allocation results from DCMF #2 1070. IMS AS #2 1060 may remove the third bootstrap data channel media description (m-line #3) from the SDP proposal and add a fourth bootstrap data channel media description (m-line #4). The third bootstrap data channel media description (m-line #3) may be a proposal for providing SCTP association with DCMF #2 1070 to UE #1 1010 by DCMF #1 1040, and the fourth bootstrap data channel media description (m-line #4) may be a proposal for establishing a bootstrap data channel between DCMF #2 1070 and UE #2 1080.

[0170] In step 1025, P / S / I-CSCF #2 1050 sends a SIP INVITE request message to UE #2 1080, which includes the modified SDP proposal received from IMS AS #2 1060.

[0171] In step 1027, UE #2 1080, which receives a SIP INVITE request message including a modified SDP proposal from P / S / I-CSCF #2 1050, can send an 18x response message to P / S / I-CSCF #2 1050. The 18x response message may include a response to the SDP proposal related to the bootstrap data channel (SDP response). Figure 10 In this context, it is assumed that UE #2 1080 has agreed to the establishment of the four boot data channels included in the second boot data channel media description (m-line #2) and the fourth boot data channel media description (m-line #4).

[0172] In step 1029, P / S / I-CSCF #2 1050 sends an 18x response message including the SDP proposal to IMS AS #2 1060.

[0173] In step 1031, IMS ASv 1060 can analyze the SDP response message, communicate with the remote DCMF #2 1070 if necessary based on the analysis results, and reallocate resources related to the boot data channel.

[0174] In step 1033, IMS AS #2 1060 modifies the SDP response and sends an 18x response message containing the same content to P / S / I-CSCF #2 1050. The modified SDP response may include operator policies or resource allocation results from DCMF #2 1070. IMS AS #2 1060 may add a third bootstrap data channel media description (m-line #3) to the SDP response and remove a fourth bootstrap data channel media description (m-line #4). The third bootstrap data channel media description (m-line #3) may be a response to DCMF #1 1040 providing SCTP association functionality with DCMF #2 1070 to UE #1 1010, and the fourth bootstrap data channel media description (m-line #4) may be a response to the establishment of a bootstrap data channel between DCMF #2 1070 and UE #2 1080.

[0175] In step 1035, P / S / I-CSCF #2 1020, which receives the 18x response message from IMS AS #2 1060, may send an 18x response message to IMS AS #1 1030 that includes the modified SDP response received from IMS AS #2 1060.

[0176] In step 1037, the IMS AS #2 1030, which receives the 18x response message from P / S / I-CSCF #2 1020, can analyze the modified SDP response included in the received 18x response message, communicate with DCMF #21040 if necessary based on the analysis results, and reallocate the bootstrap data channel related resources.

[0177] In step 1039, IMS AS #2 1030 modifies the modified SDP response and sends an 18x response message containing the same content to UE #1 1010 via P / S / I-CSCF #1 1020. The modified SDP response may include operator policies or resource allocation results from DCMF #2 1040. IMS AS #1 1030 may add a first bootstrap data channel media description (m-line #1) from the SDP proposal to the SDP response with UE #1 1010, and remove the second bootstrap data channel media description (m-line #2) and the third bootstrap data channel media description (m-line #3). The first bootstrap data channel media description (m-line #1) may be a response to the establishment of a multiplexed bootstrap data channel between UE #1 1010 and DCMF #1 1040. The second bootstrap data channel media description (m-line #2) may be a response to the establishment of a bootstrap data channel between DCMF #1 1040 and UE #2 1080, and the third bootstrap data channel media description (m-line #3) may be a response to the establishment of a bootstrap data channel from DCMF #1 1040 to UE #1 1010 to provide SCTP association functionality with DCMF #2 1070.

[0178] Subsequently, the remaining call session establishment procedure between UE #1 1010 and UE #2 1080 is executed, and UE #1 1010 and UE #2 1080 can obtain data channel application through the established bootstrap data channel.

[0179] In this paper, all two DCMFs located in different networks can support bootstrap data channel multiplexing.

[0180] Figure 11 The diagram illustrates a media plane structure in a communication system according to an embodiment, provided by two DCMFs that support guided data channel multiplexing.

[0181] refer to Figure 11UE #1 1111 and DCMF #1 1113 can connect via a first DTLS session, which may include four bootstrap data channels with flow ID values ​​“0”, “10”, “100”, and “110”. DCMF #1 11113 can perform HTTP proxy functionality for DCMF #1 1112, and for this purpose, it can use two bootstrap data channels with flow ID values ​​“0” and “10” connected to the first DTLS session of UE #1 1111, and two bootstrap data channels with flow ID values ​​“100” and “110” connected to the second DTLS session of DCMF #2 1123. DCMF #2 1123 provides SCTP association functionality with UE #2 1121.

[0182] DCMF #1 1113 can provide SCTP association functionality between DCMF #2 1123 (which performs HTTP proxy functionality for DCMF #2 1122) and UE #11111. To provide SCTP association functionality, DCMF #1 1113 and DCMF #2 1123 can connect via a third-party DTLS connection.

[0183] Figure 12 The process of establishing two multiplexed bootstrap data channels in a communication system according to an embodiment is illustrated. Figure 12 In, similar to Figure 10 In this embodiment, it is assumed that UE #1 1210, P / S / I-CSCF #1 1220, IMS AS #1 1230 and DCMF #1 1240 are located in a first network, and P / S / I-CSCF #2 1250, IMS AS #2 1260, DCMF #2 1270 and UE #2 1280 are located in a second network different from the first network.

[0184] refer to Figure 12 The UE can establish a multiplexed boot data channel and obtain data channel applications through the following process.

[0185] Steps 1211 to 1219 and Figure 10 Steps 1011 to 1019 are the same.

[0186] In step 1221, the IMS AS #2 1260, which receives the SIP INVITE request message, analyzes the pilot data channel media description in the modified SDP proposal and allocates the pilot data channel resources to the DCMF #2 1270. The IMS AS #2 1260 can obtain the information required for resource allocation from at least one of the HSS and DCSF, and this information may include information indicating whether the DCMF #2 1270 supports pilot data channel multiplexing. Figure 12 In this context, it is assumed that both DCMF #21270 and UE #2 1280 support data channel multiplexing.

[0187] In step 1223, IMS AS #2 1260 modifies the SDP proposal and sends a SIP INVITE request message containing the same content to P / S / I-CSCF #2 1250. The SDP proposal modification (or the modified SDP proposal) may include operator policies or resource allocation results from DCMF #2 1270. IMS AS #2 1260 may remove the second bootstrap data channel media description (m-line #2) and the third bootstrap data channel media description (m-line #3) from the SDP proposal and add a fourth bootstrap data channel media description (m-line #4). The second bootstrap data channel media description (m-line #2) may be a proposal from DCMF #2 1270 to UE #2 1280 to provide SCTP association functionality with DCMF #1 1240, and the third bootstrap data channel media description (m-line #3) may be a proposal from DCMF #1 1240 to UE #1 1210 to provide SCTP association functionality with DCMF #2 1270. The fourth pilot data channel media description (m-line#4) may be a proposal for establishing a pilot data channel between DCMF #2 1270 and UE #2 1280, and may include access information of DCMF #2 1270.

[0188] In step 1225, P / S / I-CSCF #2 1250 sends a SIP INVITE request message, which includes the modified SDP proposal, received from IMS AS #2 1260, to UE #2 1280.

[0189] In step 1227, UE #2 1280, having received a SIP INVITE request message including a modified SDP proposal from P / S / I-CSCF #2 1250, can send an 18x response message to P / S / I-CSCF #2 1250. The 18x response message may include a response to the SDP proposal associated with the bootstrap data channel (SDP response). Figure 12In this context, it is assumed that UE #2 1280 has agreed to the establishment of the four boot data channels included in the fourth media description (m-line #4).

[0190] Steps 1229 to 1239 and Figure 10 Steps 1029 to 1039 are the same.

[0191] Subsequently, the remaining call session establishment procedure between UE #1 1210 and UE #2 1280 is executed, and UE #1 1210 and UE #2 1280 can obtain data channel application through the established bootstrap data channel.

[0192] Therefore, the bootstrap data channel and the application data channel can be multiplexed through an SCTP association in the communication system.

[0193] Figure 13 A media plane structure in a communication system according to an embodiment is shown, in which a pilot data channel and an application data channel are multiplexed.

[0194] refer to Figure 13 UE 1310 may include a first application (application #1) 1311 obtained via a bootstrap data channel and a DCMTSI client 1312 for providing the data channel. DCMTSI client 1312 is a multimedia telephony service for a Data Channel (DC) IMS (MTSI) device supporting the data channel and may be a device compliant with relevant standards. DCMF 1320 may include a protocol stack matching the data channel protocol stack of DCMTSI client 1312, and a second application (application #2) 1321 corresponding to the first application 1311. Second application 1321 may provide a service to the first application 1311, providing all or some of the functions provided by the first application 1311, and additionally providing functions not provided by the first application 1321. Although... Figure 13 The DCMF 1320 is shown to provide a second application 1321, but the second application 1321 can be provided by a separate network device or a second UE.

[0195] During the registration process of the first UE 1310 in the IMS network or the call session establishment process, the support for multiplexing of the bootstrap data channel and the application data channel can be exchanged via SIP messages or separate protocols. For example, the characteristic capability indicator or media characteristic tag of the SIP message can be used to signal the channels to be supported.

[0196] Figure 14 The process of establishing and guiding data channel multiplexing in a communication system according to an embodiment is illustrated. Figure 14In this context, it is assumed that local DCMF 1440, local IMS AS 1430 and local DCMF 1440 are located in a local network that UE 1410 has subscribed to, and that the local network is a network different from the remote network 1450.

[0197] refer to Figure 14 UE 1410 can establish and guide the application data channel multiplexing through the following process.

[0198] In step 1401, UE 1410 establishes a bootstrap DC-DC with local DCMF 1440, having a bootstrap DC flow ID value of "0", and obtains a first data channel application through the established bootstrap DC. The first bootstrap DC media description (m-line #1) used to establish the bootstrap DC or SDP proposal, and the response including the first bootstrap DC media description (m-line #1), may include attributes indicating whether multiplexing of the bootstrap DC and the application data channel is supported. Figure 14 In the first boot DC media description (m-line#1), the attribute "a=adcmultiplexing" can be included, and when the value of the attribute "a=adcmultiplexing" is configured to "yes", it can indicate that the boot DC including the attribute "a=adcmultiplexing" can be multiplexed with the application data channel.

[0199] In step 1402, UE 1410 transmits a SIP RE-INVITE request message to local IMS AS 1430 via local P / S / I-CSCF 1420, including an application data channel establishment request for operations of the first data channel application. The SIP RE-INVITE request message may include an SDP proposal, and the first bootstrap DC media description (m-line #1) in the SDP proposal may include the attribute "a=dcmap" proposing to establish an application data channel with a flow ID value of 1024.

[0200] In step 1403, the local IMS AS 1430, receiving the SIP RE-INVITE request message, analyzes the data channel media description in the SDP proposal and allocates the resources for the applied data channel to the local DCMF 1440. The local IMS AS 1430 can obtain the information required for resource allocation from at least one of the HSS and DCSF, and this information may include information indicating whether the local DCMF 1440 supports guided DC multiplexing. Figure 14 In this context, it is assumed that local DCMF 1440 and UE1410 support the multiplexing of the bootstrap DC and application data channels.

[0201] In step 1404, the local IMS AS 1430 sends an SDP response to the SDP proposal to the UE 1410 via the local P / S / I-CSCF 1420. Depending on the location of the second data channel application corresponding to the first data channel application, the SDP response can be obtained through different procedures. For example... Figure 13 As shown, when the DCMF provides a second data channel application, the local IMS AS1430 can generate an SDP response using information provided by at least one of the network entities: the local DCSF, the local DCMF 1440, and the HSS. When the second data channel application is provided by a second network entity instead of the local DCMF 1440, the local DCMF 1440 can provide UE 1401 with SCTP association functionality with the second network entity. Additional SIP message exchange and SDP provision / response procedures for obtaining the SDP response can be performed. The second network entity may include a second UE.

[0202] In step 1405, the first channel application of UE 1410 can communicate with the second channel application by using the application data channel established by multiplexing with the existing boot DC.

[0203] The above embodiments describe a case where the information related to pilot DC multiplexing is provided as a lower attribute of the media description, including pilot DC configuration information (e.g., attribute "a=bdcmultiplexing" or attribute "a=adcmultiplexing"). Depending on the implementation, other methods can be used to notify whether application channel multiplexing functionality is supported. For example, whether application channel multiplexing is supported can be signaled at the real-time communication service session level via at least one of SDP and SIP messages. For example, the SDP may include the attribute "a=bdcmultiplexing" or the attribute "a=adcmultiplexing" as a session-level attribute, rather than a lower attribute of a specific media description. In another example, the SIP message may include a code corresponding to the attribute value "bdcmultiplexing" or "adcmultiplexing" as a +sip.app-subtype media feature label or feature capability indicator.

[0204] Therefore, an application data channel in the communication system can be established between the first UE and the second UE, or between the first UE and the first server. From the perspective of the first UE, application data channels with different terminals can be multiplexed through an SCTP association. This is called ATDE multiplexing.

[0205] Figure 15 A media plane structure supporting ATDE multiplexing is shown in a communication system according to an embodiment.

[0206] refer to Figure 15 The first UE 1510 may include a first application 1511 acquired via a bootstrap DC and a first DCMTSI client 1512 for providing a data channel. The first DCMTSI client 1512 is a Multimedia Telephony Service (IMS) (MTSI) device supporting the data channel and may be a device compliant with all or some of the relevant standards. The network 1520 may include a protocol stack matching the data channel protocol stack of the first DCMTSI client 1512 and may be an IMS Access Gateway (IMS-AGW) or a DCMF. Similar to the first UE 1510, the second UE 1530 may include a first application 1532 acquired via a bootstrap DC and a second DCMTSI client 1531 for providing a data channel. The server 1540 may include a third application 1542 and a third DCMTSI client 1541 for providing a data channel, and the third application 1542 and the third DCMTSI client 1541 may be implemented as separate devices. The first application 1511, the second application 1532, and the third application 1542 may provide a service and may include all or some of the functions required to provide a service, depending on the service provider's selection.

[0207] The first SCTP association established between network 1520 and the first UE 1510 may include one or more application data channels, and these application data channels may have different endpoints. For example, the first application data channel (ADC#1) may include data to be exchanged between the first application 1511 and the second application 1532, and the second application data channel (ADC#2) may include data to be exchanged between the first application 1511 and the third application 1542. Network 1520 may establish a second SCTP association with the second UE 1530 to exchange data for ADC#1. Similarly, network 1520 may establish a third SCTP association with server 1540 to exchange data for ADC#2.

[0208] Network 1520 and server 1540 can be integrated into a single device or implemented separately as more detailed devices, and the presence or absence of a third SCTP association can depend on the implementation method. For example, IMS-AGW can perform the functions of network 1520, while DCMF can perform the functions of server 1540. In this case, IMS-AGW and DCMF can establish a third SCTP association to exchange data. In another example, DCMF can perform the functions of both network 1520 and server 1540. In this case, the third SCTP association can be replaced by an interface within the device. The third application 1542 can exchange data on the second application data channel with network 1520 using another application protocol. In this case, the third SCTP association can be replaced by a protocol stack based on the application protocol used by the second application 1531.

[0209] During the UE 1310's registration process in the IMS network or the call session establishment process, the support for ATDE multiplexing can be exchanged via SIP messages or a separate protocol. For example, ATDE multiplexing can be signaled using a feature capability indicator or media feature tag in a SIP message, or as an attribute of the SDP included in the SIP message.

[0210] Figure 16 The process of establishing and exchanging application data channels using ATDE multiplexing in a communication system according to an embodiment is illustrated. Figure 16 In this context, it is assumed that local IMS AS 1630, local IMS-AGW 1640, and local DCMF 1650 are located in a local network to which local UE 1610 has subscribed, and that this local network is different from the remote network 1670. It is also assumed that local IMS-AGW 1640 provides... Figure 15 The network 1520 provides functionality, while the local DCMF 1650 provides the same functionality. Figure 15 The third DCMTSCI client 1541 of the server 1540 in the middle provides the functionality, and DC AS 1660 provides Figure 15 The third application, 1542, is a function.

[0211] refer to Figure 16 The local UE 1610 can establish a data channel multiplexed with ATDE to exchange data through the following process.

[0212] In step 1601, local UE 1610 and remote UE 1680 establish a bootstrap DC with local DCMF 1650, obtain the data channel application (AppA) through the bootstrap DC, and execute the data channel application. It is assumed that support for ATDE multiplexing is recognized by local UE 1610 and the local network during this process.

[0213] In step 1602, the local UE 1610 transmits an SDP proposal for establishing an application data channel to the local IMS AS 1630 via the local P / S / I-CSCF 1620. For example, the first media description (m-line#1) in the SDP proposal may include a first application data channel with a flow ID value of 1000 and a second application data channel with a flow ID value of 1001. The first media description (m-line#1) may include the attribute "a=AppInfo", thereby indicating that the data channel application (AppA) obtained in step 1601 requests to establish a first application data channel (flow ID = 1000) with the remote UE 1680 and requests to establish a second application data channel (flow ID = 1001) with the DC AS 1660.

[0214] In step 1603, the local IMS AS 1630, which receives the SDP proposal, allocates resources for supporting ATDE multiplexing to the local IMS-AGW 1640 and the local DCMF 1650. The local IMS AS 1630 can collect the information required for resource allocation from another network function. Communication with the local IMS-AGW 1640 and the local DCMF 1650 for resource allocation can be performed through another network function.

[0215] In step 1604, the local IMS AS 1630 performs an SDP proposal / response procedure to establish a first application data channel (flow ID = 1000) between the local IMS-AGW 1640 and the remote UE 1680. The SDP used for the SDP proposal / response procedure may include a second media description (m-line #2) that provides information for establishing a second SCTP association between the local IMS-AGW 1640 and the remote UE 1680. The signaling transmission path used to perform the SDP proposal / response procedure may include another network function located in the remote network 1670, and this other network function may be involved in the SDP proposal / response procedure. For example, the procedure for the ATDE multiplexing function of the remote network 1670 may be performed.

[0216] In step 1605, local IMS AS 1630 and DC AS 1660 perform an SDP proposal / response procedure to establish a second application data channel (flow ID = 1001) between local IMS-AGW 1640 and DC AS 1660. The SDP used for the SDP proposal / response procedure may include a third media description (m-line #3), which provides information for establishing a third SCTP association between local IMS-AGW 1640 and local DCMF 1650. Another network function may reside in the signaling transmission path used to perform the SDP proposal / response procedure, and local IMS AS 1630 and DC AS 1660 may obtain information for making the SDP proposal / response from this other network function.

[0217] In step 1606, the local IMS AS 1630 transmits an SDP response to the SDP proposal provided by the local UE 1610 in step 1602, based on the second media description (m-line #2) and the third media description (m-line #3) negotiated in steps 1604 and 1605. Resources of the local IMS-AGW 1640 or the local DCMF 1650 can be controlled according to the negotiation results of the second media description (m-line #2) and the third media description (m-line #3).

[0218] In step 1607, the local UE 1610 establishes a first SCTP association with the local IMS-AGW 1640 based on the negotiation result of the first media description (m-line#1), and exchanges data through the first application data channel (stream ID = 1000) and the second application data channel (stream ID = 1001).

[0219] In step 1608, the local IMS-AGW 1640 establishes a second SCTP association with the remote UE 1680 based on the negotiation result of the second media description (m-line#2) and exchanges data through the first application data channel (stream ID = 1000).

[0220] In step 1609, the local IMS-AGW 1640 establishes a third SCTP association with the DC AS 1660 based on the negotiation result of the third media description (m-line#3) and exchanges data through the second application data channel (stream ID = 1001).

[0221] The above process describes the signaling and application data channel exchange between local UE 1610, the local network, and DC AS 1660 when local UE 1610 and the local network use ATDE multiplexing. This process can also be applied when remote network 1670 and remote UE 1680 use ATDE. When the UE and network do not agree to use ATDE multiplexing, the UE should request to establish an application data channel using a different media description (m-line) for each endpoint. For example, the SDP proposal in step 1602 can be configured as follows.

[0222] m-line#1

[0223] a = dcmap: 1000

[0224] a = AppInfo: AppA 1000;UE

[0225] m-line#1

[0226] a = dcmap: 1001

[0227] a = AppInfo: AppA 1001;Server

[0228] exist Figure 16 In this process, the boot setup procedure (operation 1601) may include a process of negotiating whether ATDE multiplexing using SDP is supported. For example, a media description that includes information about the boot DC may include the attribute "a=atdemultiplexing".

[0229] Figure 17a and Figure 17b An indication of whether negotiation using ATDE multiplexing with SDP is supported is shown in a communication system according to an embodiment.

[0230] refer to Figure 17a and Figure 17b Steps 1710 to 1714 instruct the local UE 1610 to send an SDP proposal to the remote network for establishing a bootstrap DC (BDC).

[0231] In step 1710, the local UE 1610 initiates a bootstrap DC establishment process for acquiring data channel applications.

[0232] In step 1711, if the local UE 1610 supports ATDE multiplexing, operation 1712 is executed; if the local UE 1610 does not support this operation, operation 1713 is executed.

[0233] In step 1712, the local UE 1610 generates an SDP proposal that includes a first media description for establishing the bootstrap DC. The first media description may include the attribute "a=atdemultiplexing".

[0234] In step 1713, the local UE 1610 generates an SDP proposal that includes a first media description for establishing the bootstrap DC. The first media description does not include the attribute "a=atdemultiplexing".

[0235] In step 1714, the local UE 1610 transmits the generated SDP proposal to the local network.

[0236] Steps 1720 to 1721 indicate the process in which the local network processes the received SDP proposal and sends the SDP proposal to the remote network 1670.

[0237] In step 1720, the local network processes the received SDP proposal and generates a modified SDP proposal. When the local UE1610 and the local network support ATDE multiplexing, the SDP proposal processing may include resource allocation for supporting ATDE multiplexing.

[0238] In step 1721, the local network transmits the modified SDP proposal generated in step 1720 to the remote network 1670.

[0239] Steps 1730 to 1733 indicate the process in which the remote network 1670 processes the received modified SDP proposal and sends the SDP proposal to the remote UE 1680.

[0240] In step 1730, it is determined whether the remote network 1670 supports ATDE multiplexing. If the remote network 1670 supports ATDE multiplexing, step 1731 is executed; if the remote network 1670 does not support ATDE multiplexing, step 1732 is executed.

[0241] In step 1731, the remote network 1670 processes the received SDP proposal and generates an SDP proposal including modifications to a second media description for establishing a bootstrap DC. The second media description may include the attribute "a=atdemultiplexing". The SDP proposal processing may include resource allocation for supporting ATDE multiplexing.

[0242] In step 1732, the remote network 1670 processes the received SDP proposal and generates an SDP proposal that includes modifications to a second media description for establishing a bootstrap DC. The second media description does not include the attribute "a=atdemultiplexing".

[0243] In step 1733, the remote network 1670 transmits the generated modified SDP proposal to the remote UE 1680.

[0244] Steps 1740 to 1743 instruct the process in which the remote UE 1680 sends an SDP response to the remote network 1670 for establishing a bootstrap DC (BDC).

[0245] In step 1740, it is determined whether the remote UE 1680 and the remote network 1670 support ATDE multiplexing. If the remote UE 1680 and the remote network 1670 support ATDE multiplexing, step 1741 is executed; if the remote UE 1680 and the remote network 1670 do not support ATDE multiplexing, step 1742 is executed. Whether the remote network 1670 supports ATDE multiplexing can be determined based on whether the received modified SDP proposal includes the attribute "a=atdemultiplexing".

[0246] In step 1741, the remote UE 1680 generates an SDP response that includes a second media description for establishing a bootstrap DC. The second media description may include the attribute "a=atdemultiplexing".

[0247] In step 1742, the remote UE 1680 generates an SDP response that includes a second media description for establishing a bootstrap DC. The second media description does not include the attribute "a=atdemultiplexing".

[0248] In step 1743, the remote UE 1680 transmits the generated SDP response to the remote network 1670.

[0249] Steps 1744 to 1749 instruct the process in which the remote network 1670 processes the received SDP response and sends the SDP response to the local network.

[0250] In step 1744, the remote network 1670 processes the received SDP response and generates a modified SDP response. When the remote network 1670 supports ATDE multiplexing, the SDP response processing may include resource allocation for supporting ATDE multiplexing.

[0251] In step 1745, the remote network 1670 transmits the modified SDP response generated in step 1744 to the local network.

[0252] Steps 1746 to 1749 indicate the process in which the local network processes the received modified SDP response and sends the SDP response to the local UE 1610.

[0253] In step 1746, determine whether the local network supports ATDE multiplexing. If the local network supports ATDE multiplexing, proceed to step 1747; if the local network does not support ATDE multiplexing, proceed to step 1748.

[0254] In step 1747, the local network processes the received modified SDP response and generates a modified SDP response including a first media description for establishing the bootstrap DC for the local UE1610. The first media description may include the attribute "a=atdemultiplexing". The modified SDP response processing may include resource allocation for supporting ATDE multiplexing.

[0255] In step 1748, the local network processes the received modified SDP response and generates a modified SDP response including a first media description for establishing the bootstrap DC for the local UE1610. The first media description does not include the attribute "a=atdemultiplexing".

[0256] In step 1749, the local network transmits the generated modified SDP response to the local UE 1610.

[0257] In the communication system described herein, the client sends a request for the root URL (“ / ”) to the data channel server via a bootstrap DC to obtain a data channel application. The data channel server receiving the request for the root URL can select a data channel application based on a data channel application selection reference and provide the selected application. The data channel application selection reference may include information related to bootstrap DC multiplexing.

[0258] Figure 18 The internal structure of a network entity in a wireless communication system according to an embodiment is shown.

[0259] Figure 18 The internal structure of network entity 1800 shown is merely an example, and the internal structure of network entity 1800 can vary.

[0260] refer to Figure 18 Network entity 1800 includes multiple antennas 1805a to 1805n, multiple radio frequency (RF) transceivers 1810a to 1810n, transmit (TX) processing circuitry 1815, and receive (RX) processing circuitry 1820. Network entity 1800 also includes a controller / processor 1825, a memory 1830, and a backhaul or network interface (IF) 1835.

[0261] RF transceivers 1810a to 1810n receive input RF signals, such as signals transmitted by a UE in a wireless communication network, from antennas 1805a to 1805n. RF transceivers 1810a to 1810n generate IF or baseband signals by down-converting the input RF signals. The IF or baseband signals are sent to RX processing circuitry 1820, which generates a processed baseband signal by filtering, decoding, and / or digitizing the baseband or IF signals. RX processing circuitry 1820 sends the processed baseband signal to controller / processor 1825 for further processing.

[0262] The TX processing circuit 1815 receives analog or digital data (such as voice data, web data, email, or interactive video game data) from the controller / processor 1825. The TX processing circuit 1815 generates a processed baseband or IF signal by encoding, multiplexing, and / or digitizing the output baseband data. RF transceivers 1810a to 1810n receive the processed baseband or IF signal output from the TX processing circuit 1815 and up-convert the baseband or IF signal into an RF signal transmitted through antennas 1805a to 1805n.

[0263] The controller / processor 1825 may include one or more processors or other processing devices for controlling the overall operation of the network entity 1800. The network entity 1800 may be... Figures 1 to 14 This refers to one of the various network entities described (e.g., IMSAS, IMS HSS, data channel server, DC application server, etc.). The overall operation of network entity 1800 can be implemented in conjunction with... Figures 1 to 1 The operations described in section 7 are similar or substantially the same, therefore a detailed description of them is omitted.

[0264] For example, controller / processor 1825 can control RF transceivers 1810a to 1810n, RX processing circuitry 1820, and TX processing circuitry 1815 to receive forward channel signals and transmit backward channel signals according to known principles. Controller / processor 1825 can support additional functions, such as more advanced wireless communication functions. For example, controller / processor 1825 in network entity 1800 can support one of various other functions. Controller / processor 1825 may include at least one microprocessor or microcontroller. Controller / processor 1825 can be implemented as at least one processor and may be referred to as a "processor".

[0265] The controller / processor 1825 can execute programs and other processes, such as an operating system, residing in memory 1830. The controller / processor 1825 can move data required by the executed process to memory 1830 or externally. The controller / processor 1825 can support communication between network entities. The controller / processor 1825 can move data to memory 1830 or externally depending on the executed process.

[0266] The controller / processor 1825 is connected to the backhaul or network IF 1835. The backhaul or network IF 1835 allows network entity 1800 to communicate with other devices or systems via backhaul communication or a network. The backhaul or network IF 1835 can support communication via suitable wired or wireless communication. For example, when network entity 1800 is implemented as part of a cellular communication system (such as a cellular communication system supporting 5G NR, Long Term Evolution (LTE), or Advanced Long Term Evolution (LTE-A)), the backhaul or network IF 1835 can allow network entity 1800 to communicate with other network entities via wired or wireless backhaul communication. When network entity 1800 is implemented as an access point, the backhaul or network IF 1835 can allow network entity 1800 to perform communication via a wired or wireless local area communication network or via a larger network (such as the Internet) through a wired or wireless connection. The backhaul or network IF 1835 includes suitable infrastructure supporting communication via wired or wireless connections, such as Ethernet or RF transceivers.

[0267] although Figure 18 An example of network entity 1800 is shown, but it can be seen in... Figure 18 Various modifications can be made. For example, network entity 1150 may include... Figure 11 The predetermined number of components shown. For example, an access point may include multiple backhaul or network interfaces 1835, and a controller / processor 1825 may support routing functionality for data between different network addresses. Additionally, although a single instance of the TX processing circuitry 1815 and a single instance of the RX processing circuitry 1820 are shown, the network entity 1800 may include multiple instances (such as one instance per RF transceiver). Furthermore, in Figure 18 In this system, various components can be combined, additionally divided, or omitted, and additional components can be added as needed.

[0268] Figure 19 The internal structure of a UE in a wireless communication system according to an embodiment is shown.

[0269] Figure 19 The internal structure of UE 1900 shown is merely an example, and the internal structure of UE 1900 may not be limited to this. Figure 19 The implementation shown in the figure.

[0270] refer to Figure 19 UE 1900 includes an antenna 1905, a radio frequency (RF) transceiver 1910, a TX processing circuit 1915, a microphone 1920, and an RX processing circuit 1925. UE 1900 also includes a speaker 1930, a controller / processor 1940, an input / output (I / O) IF 1945, an input device 1950, a display 1955, and memory 1960. Memory 1960 includes an operating system (OS) 1961 and one or more applications 1962.

[0271] RF transceiver 1910 receives input RF signals transmitted by a network entity of a wireless communication network from antenna 1905. RF transceiver 1910 down-converts the input RF signals to generate an intermediate frequency (IF) or baseband signal. The IF or baseband signal is sent to RX processing circuitry 1925, which generates a processed baseband signal by filtering, decoding, and / or digitizing the baseband or IF signal. RX processing circuitry 1925 sends the processed baseband signal to speaker 1930 (for voice data) or processor 1940 (for web browsing data) for further processing.

[0272] The TX processing circuit 1915 receives analog or digital voice data from the microphone 1920, or various output baseband data (such as web data, email, or interactive video game data) from the processor 1940. The TX processing circuit 1915 generates a processed baseband or intermediate frequency (IF) signal by encoding, multiplexing, and / or digitizing the output baseband data. The RF transceiver 1910 receives the processed baseband or IF signal from the TX processing circuit 1915 and up-converts it into an RF signal transmitted via the antenna 1905.

[0273] The controller / processor 1940 may include one or more processors or other processing devices and executes the OS 1961 stored in memory 1960 to control the overall operation of the UE 1900. The operation of the UE 1900 can be implemented in conjunction with... Figures 1 to 1 The operations described in section 7 are similar or substantially the same, therefore, their description is omitted here. For example, controller / processor 1940 can control the RF transceiver 1910, RX processing circuit 1925, and TX processing circuit 1915 to receive forward channel signals and transmit backward channel signals according to known principles. Controller / processor 1940 includes at least one microprocessor or microcontroller.

[0274] The controller / processor 1940 can also execute other processes and programs in the memory 1960, such as processes for beam management. When needed by the executing processor, the controller / processor 1940 can move data to or from the memory 1960. The processor 1940 can be configured to execute applications 1962 based on OS programs 1961 or in response to signals received from network entities or operators. The controller / processor 1940 is connected to the I / O IF 1945, and the I / O IF 1945 provides the UE 1900 with connectivity to other devices such as laptops and handheld computers. The I / O IF 1945 is the communication path between the accessory and the processor 1940.

[0275] The controller / processor 1940 is also connected to the input device 1950 and the display unit 1955. The operator of the UE 1900 can input data to the UE 1900 using the input device 1950. The input device 1950 can be another device capable of acting as a user interface allowing keyboard, touchscreen, mouse, trackball, voice input, or user interaction with the UE 1900. In another example, the input device 1950 may include a touch panel, a (digital) pen sensor, buttons, or an ultrasonic input device. The touch panel can recognize touch input using at least one of capacitive, resistive, infrared, or ultrasonic methods.

[0276] The controller / processor 1940 is also connected to the display 1955. The display 1955 may be a liquid crystal display, an organic light-emitting diode display, or another display capable of displaying text and / or limited graphics from a website.

[0277] Memory 1960 is connected to processor 1940. A portion of memory 1960 may include random access memory (RAM), and the remainder of memory 1960 may include flash memory or other read-only memory (ROM).

[0278] although Figure 19 An example of UE 1900 is shown, but in Figure 19 Various modifications can be made within it. For example, in Figure 19 In this system, various components can be combined, additionally divided, omitted, or additional components can be added as needed. As a specific example, the controller / processor 1940 can be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). The controller / processor 1940 can be implemented as at least one processor and can be referred to as a "processor". Although... Figure 19The UE 1900 is shown to include a mobile phone or smartphone, but the UE can be configured to operate as other types of mobile or fixed devices.

[0279] The electronic device that implements, operates, and performs embodiments of this disclosure can be one of various types of electronic devices, including but not limited to portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances.

[0280] As used herein, the term "module" can include a unit implemented in hardware, software, or firmware, and can be used interchangeably with the terms "logic," "logic block," "component," or "circuit." A module can be a single integrated component or its smallest unit or portion adapted to perform one or more functions. For example, a module can be implemented as an application-specific integrated circuit (ASIC).

[0281] The various embodiments described herein can be implemented as software (e.g., a program) comprising one or more instructions stored in a machine-readable storage medium (e.g., internal or external memory). For example, a processor of a machine (e.g., an electronic device) can invoke and execute at least one of the one or more instructions stored in the storage medium. This allows the machine to be operated to perform at least one function according to the invoked at least one instruction. Each of the one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. The term "non-transitory" means that the storage medium is a tangible device and does not include signals, nor does it distinguish whether data is stored semi-permanently or temporarily in the storage medium.

[0282] The method according to the embodiments can be included and provided in a computer program product transacted between a seller and a buyer. The computer program product can be distributed in the form of a machine-readable storage medium (e.g., an optical disc read-only memory (CD-ROM)), or can be downloaded or uploaded online via an app store (e.g., the Play Store™), or downloaded or uploaded directly between two user devices. If distributed online, at least a portion of the computer program product can be temporarily generated or at least temporarily stored in a machine-readable storage medium, such as the memory of a manufacturer's server, an app store's server, or a relay server.

[0283] In this document, each of the aforementioned elements (e.g., a module or program) may include a single entity or multiple entities, and some of the multiple entities may be arranged separately in another element. One or more of the aforementioned elements or operations may be omitted, or one or more other elements or operations may be added. Optionally or additionally, multiple modules or programs may be integrated into a single element. In this case, the integrated element may still perform one or more functions of each of the multiple elements in the same or similar manner as they were performed by a corresponding element among the multiple elements prior to integration. Operations performed by a module, program, or other element may be performed sequentially, in parallel, repeatedly, or heuristically, or one or more operations may be performed in a different order or omitted, or one or more other operations may be added.

[0284] In this document, each box in the flowchart illustrations, and combinations of boxes in the flowchart illustrations, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create instructions for implementing the functions specified in one or more boxes of the flowchart. These computer program instructions can also be stored in a computer-usable or computer-readable storage medium, which can instruct the computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-usable or computer-readable storage medium produce an article of manufacture including instructions for implementing the functions specified in one or more boxes of the flowchart. The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus, thereby producing a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more boxes of the flowchart.

[0285] Each box in a flowchart diagram can represent a module, code segment, or code section, which includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the boxes may not appear in a specific order. For example, two boxes shown consecutively may actually be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order, depending on the functions involved.

[0286] Although this disclosure has been described and illustrated with reference to various embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made without departing from the spirit and scope of this disclosure as defined by the appended claims and their equivalents.

Claims

1. A method for a user equipment (UE) in a wireless communication system, the method comprising: Send a first message to the network entity, including a Session Description Protocol (SDP) proposal; as well as Receive a second message from the network entity, including an SDP response corresponding to the SDP proposal. The SDP proposal includes at least one data channel stream identifier for guiding the data channel and a first attribute related to data channel multiplexing, and The SDP response includes the network entity's access information and first attribute.

2. The method according to claim 1, in, The first attribute included in the SDP proposal has an attribute value that indicates that the UE supports data channel multiplexing.

3. The method according to claim 1, in, The first attribute included in the SDP response has an attribute value that indicates that the network entity supports data channel multiplexing.

4. The method according to claim 1, in, The UE is associated with a Flow Control Transport Protocol (SCTP) with another network entity besides the aforementioned network entity. In the case of SCTP association, the network entity and the other network entity are connected via a Datagram Transport Layer Security (DTLS) session.

5. A method for a network entity in a wireless communication system, the method comprising: Receive a first message from the user equipment (UE) including a Session Description Protocol (SDP) proposal; as well as Send a second message to the UE, including an SDP response corresponding to the SDP proposal. The SDP proposal includes at least one data channel stream identifier for guiding the data channel and a first attribute related to data channel multiplexing, and The SDP response includes the network entity's access information and first attribute.

6. The method according to claim 5, in, The first attribute included in the SDP proposal has an attribute value that indicates that the UE supports data channel multiplexing.

7. The method according to claim 5, in, The first attribute included in the SDP response has an attribute value that indicates that the network entity supports data channel multiplexing.

8. The method according to claim 5, in, The network entity supports Flow Control Transport Protocol (SCTP) association between the UE and another network entity. In the case of SCTP association, the network entity connects to another network entity through a Datagram Transport Layer Security (DTLS) session.

9. A user equipment (UE) in a wireless communication system, the UE comprising: transceiver; as well as At least one processor is connected to the transceiver and is configured to: The transceiver sends a first message, including a Session Description Protocol (SDP) proposal, to the network entity; and Receive a second message from the network entity, including an SDP response corresponding to the SDP proposal. The SDP proposal includes at least one data channel stream identifier for guiding the data channel and a first attribute related to data channel multiplexing, and The SDP response includes the network entity's access information and first attribute.

10. The UE according to claim 9, in, The first attribute included in the SDP proposal has an attribute value that indicates that the UE supports data channel multiplexing.

11. The UE according to claim 9, in, The first attribute included in the SDP response has an attribute value that indicates that the network entity supports data channel multiplexing.

12. The UE according to claim 9, in, The UE is associated with a Flow Control Transport Protocol (SCTP) with another network entity besides the aforementioned network entity. In the case of SCTP association, the network entity and the other network entity are connected via a Datagram Transport Layer Security (DTLS) session.

13. A network entity in a wireless communication system, the network entity comprising: transceiver; as well as At least one processor is connected to the transceiver and is configured to: Receive a first message, including a Session Description Protocol (SDP) proposal, from the User Equipment (UE) via transceiver; and Send a second message to the UE, including an SDP response corresponding to the SDP proposal. The SDP proposal includes at least one data channel stream identifier for guiding the data channel and a first attribute related to data channel multiplexing, and The SDP response includes the network entity's access information and first attribute.

14. The network entity according to claim 13, in, The first attribute included in the SDP proposal has an attribute value that indicates the UE supports data channel multiplexing. The first attribute included in the SDP response has an attribute value that indicates that the network entity supports data channel multiplexing.

15. The network entity according to claim 13, in, The at least one processor is configured to support Flow Control Transport Protocol (SCTP) association between the UE and another network entity. In the case of SCTP association, the at least one processor is configured to connect to the other network entity via a Datagram Transport Layer Security (DTLS) session.