User equipment for providing reliable application data delivery and method thereof

Abstract

A user equipment including a wireless transceiver and a controller is provided. The wireless transceiver performs transmission and reception to and from a mobile communication network. The controller determines whether the mobile communication network supports IMS service. The controller establishes a packet data network connection or protocol data unit session with the mobile communication network for IMS service via the wireless transceiver in response to the mobile communication network supporting IMS service. The controller transmits application data in the packet data network connection or protocol data unit session via the wireless transceiver. This invention achieves the beneficial effect of improved reliability.

Description

TECHNICAL FIELD

[0001] The present application relates generally to mobile communications, and more particularly to an apparatus for providing reliable application data delivery and a method thereof. BACKGROUND

[0002] In a typical mobile communication environment, a UE (also called a mobile station (MS)) having a wireless communication capability such as a mobile phone (also called a cellular phone or a cell phone) or a tablet Personal Computer (PC) can transmit voice and / or data signals to one or more mobile communication networks. The wireless communication between the UE and the mobile communication network can be performed using various Radio Access Technologies (RATs), for example, Global System for Mobile communication (GSM) technology, General Packet Radio Service (GPRS) technology, Enhanced Data rates for Global Evolution (EDGE) technology, Wideband Code Division Multiple Access (WCDMA) technology, Code Division Multiple Access 2000 (CDMA-2000) technology, Time Division-Synchronous Code Division Multiple Access (TD-SCDMA) technology, Worldwide Interoperability for Microwave Access (WiMAX) technology, Long Term Evolution (LTE) technology, and LTE-Advanced (LTE-A) technology, etc. Specifically, the GSM / GPRS / EDGE technology is also called a 2G technology; the WCDMA / CDMA-2000 / TD-SCDMA technology is also called a 3G technology; and the LTE / LTE-A / TD-LTE technology is also called a 4G technology.

[0003] These RAT technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate on a municipal, national, regional, and even global level. An example of an emerging telecommunication standard for mobile communications is 5G New Radio (NR). 5G NR is a set of enhancements to the LTE mobile standard promulgated by Third Generation Partnership Project (3GPP). It is designed to better support mobile broadband Internet access by improving spectral efficiency, lowering costs, improving services, and making use of new spectrum. NR

[0004] In 4G / 5G networks, IP Multimedia Subsystem (IMS) can be deployed to provide a reliable way of establishing a signaling plane between two or more UEs. For example, in Voice over LTE or Voice over NR, voice data is propagated on the signaling plane to provide a reliable and dedicated Quality of Service (QoS). SUMMARY

[0005] The present application proposes solutions for providing a reliable way of transferring specific application data, such as gaming data, virtual reality (VR) / augmented reality (AR) / mixed reality (MR) data, and medical data. In a session-based solution, application data is allowed to be transferred based on Real-Time Transport Protocol (RTP) streams established in IMS sessions (e.g., IMS Voice over Packet-Switched (IMS VoPS) sessions or IMS Data over PS (IMS DoPS) sessions), regardless of whether the operator (e.g., the operator of a mobile communication network) is aware of such specific data transfer scenarios. In a non-session-based solution, application data is allowed to be transferred in Session Initiation Protocol (SIP) messages (e.g., in Short Message Service (SMS) messages within SIP messages) without the operator being aware of such specific data transfer scenarios.

[0006] In one aspect of this application, a user equipment (UE) including a wireless transceiver and a controller is provided. The wireless transceiver is configured to perform transmission and reception to and from a mobile communication network. The controller is configured to: determine whether the mobile communication network supports IMS service; establish a Packet Data Network (PDN) connection or Protocol Data Unit (PDU) session with the mobile communication network for the IMS service via the wireless transceiver, in response to the mobile communication network supporting the IMS service; and transmit application data via the wireless transceiver in the PDN connection or the PDU session.

[0007] In another aspect of this application, a method performed by a UE is provided, the method comprising the following steps: determining whether the mobile communication network supports IMS service; establishing a Packet Data Network (PDN) connection or Protocol Data Unit (PDU) session with the mobile communication network for the IMS service, in response to the mobile communication network supporting the IMS service; and transmitting application data in the PDN connection or the PDU session.

[0008] In one embodiment, the IMS service includes IMS voice service. Furthermore, the UE may send a first Session Initiation Protocol (SIP) invitation message including a Session Description Protocol (SDP) attribute, wherein the SDP attribute indicates that the application data should be sent in the PDN connection or PDU session using a Real-Time Protocol (RTP) stream or a video RTP stream. For example, the SDP attribute includes a session name field indicating an IMSDoPS session, a session information field indicating the type and identifier of the application data, and a media information field indicating audio RTP or video RTP. Additionally, the UE may send a first SIP INVITE message to initiate a voice call session before sending the second SIP INVITE message, and the second SIP INVITE message may be sent to modify the voice call session into an IMSDoPS session. Alternatively, the application data may be sent within the SIP message.

[0009] In another embodiment, the IMS service includes IMS data service. Furthermore, the UE may send a SIP INVITE message including a header field indicating that the application data is sent using an audio RTP stream or a video RTP stream within the PDN connection or the PDU session. For example, the header field may include a subject indication indicating the IMSDoPS session and a reason indication indicating the type and identifier of the application data.

[0010] This invention proposes a user equipment and method for providing reliable application data transmission, achieving the beneficial effect of improving reliability.

[0011] Other aspects and features of this application will become apparent to those skilled in the art from the following description of specific embodiments of the apparatus and methods for providing reliable application data transfer. Attached Figure Description

[0012] A more comprehensive understanding of this application can be obtained by referring to the accompanying drawings and reading the following detailed description and examples, in which:

[0013] Figure 1 This is a block diagram of a wireless communication environment according to an embodiment of this application;

[0014] Figure 2 A block diagram illustrating a UE 110 according to an embodiment of this application;

[0015] Figure 3 A flowchart illustrating a method for providing reliable application data transfer according to embodiments of this application;

[0016] Figure 4A and 4B An example of a so-called configuration for an operator-unknown mode, which involves mapping the parameters to the corresponding parameters, is shown.

[0017] Figure 5 This is a message sequence diagram illustrating a session-based solution for transmitting game data using an operator-unknown mode, according to an embodiment of this application.

[0018] Figure 6A and 6B A message sequence diagram is shown for a session-based solution for transmitting game data using an operator-unknown mode, according to another embodiment of this application.

[0019] Figure 7 This is a message sequence diagram illustrating a session-based solution for transmitting game data using an operator-unknown mode, according to an embodiment of this application.

[0020] Figure 8A and 8BA message sequence diagram is shown for a session-based solution for transmitting game data using a known operator pattern, according to an embodiment of this application.

[0021] Figure 9A and 9B A message sequence diagram is shown for a non-session-based solution for transmitting game data using an operator-unknown mode, according to an embodiment of this application. Detailed Implementation

[0022] The purpose of the following description is to illustrate the basic principles of this application and should not be construed as limiting. It should be understood that embodiments may be implemented in software, hardware, firmware, or any combination thereof. The terms “comprising,” “including,” “including,” and / or “comprising,” as used herein, specify the presence of the stated feature, integer, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or combinations thereof.

[0023] Figure 1 This is a block diagram of a wireless communication environment according to an embodiment of this application.

[0024] like Figure 1 As shown, the wireless communication environment 100 includes User Equipment (UE) 110, a mobile communication network 120, and an IP Multimedia Subsystem (IMS) network 130 (e.g., deployed by the operator of the mobile communication network 120). In another embodiment, the IMS network 130 may be incorporated into the mobile communication network 120.

[0025] UE 110 can be a feature phone, smartphone, panel personal computer (PC), laptop computer, machine type communication (MTC) device, or any mobile communication device that supports RAT used by mobile communication network 120. UE 110 can connect to mobile communication network 120 to obtain voice and / or data services.

[0026] Mobile communication network 120 may include access network 121 and core network 122. Access network 121 is responsible for processing radio signals, terminating radio protocols, and connecting UE 110 to core network 122, while core network 122 is responsible for performing mobility management, network-side authentication, and interfacing with public / external networks (e.g., IMS network 130 and / or the Internet).

[0027] In one embodiment, if the mobile communication network 120 is a 4G network (e.g., an LTE / LTE-A / TD-LTE network), then the access network 121 may be an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) and the core network 122 may be an Evolved Packet Core (EPC). The E-UTRAN may include at least an evolved Node B (eNB) (e.g., a macro eNB, a femto eNB, or a pico eNB). The EPC may include a Home Subscriber Server (HSS), a Mobility Management Entity (MME), a Serving Gateway (S-GW), and a Packet Data Network Gateway (PDN-GW or P-GW).

[0028] In one embodiment, if the wireless communication network 120 is a 5G network (e.g., an NR network), then the access network 121 may be a Next Generation Radio Access Network (NG-RAN) and the core network 122 may be a Next Generation Core Network (NG-CN). NG-RAN may include one or more gNBs. Each gNB may also include one or more Transmission Reception Points (TRPs), and each gNB or TRP may be referred to as a 5G cell. Some gNB functions may be distributed across different TRPs, while other functions may be centralized, preserving the flexibility and scope of specific deployments to meet the requirements of specific situations. NG-CN can support a variety of network functions, including AMF, Session Management Function (SMF), User Plane Function (UPF), Policy Control Function (PCF), Application Function (AF), Authentication Server Function (AUSF), and Non-3GPP Inter-Working Function (N3IWF). Each network function can be implemented as a network element on dedicated hardware, a software instance running on dedicated hardware, or a virtualized function instantiated on a suitable platform (e.g., cloud infrastructure).

[0029] IMS network 130 is a system comprised of various network functions used to provide IP multimedia services to UE 110 via mobile communication network 120. For example, IMS network 130 may include a SIP application server and an IMS core, wherein the IMS core includes at least an HSS, a Call Session Control Function (CSCF), a Signaling Gateway (SGW), a Media Gateway Control Function (MGCF), and a Media Resource Function (MRF). The HSS typically refers to the master database used to maintain all user profile information for authenticating and verifying users. The CSCF is the core of the IMS architecture, responsible for controlling the session between endpoints (referred to as terminals in the IMS specification) and applications. The SGW and MGCF are responsible for providing interoperability with the Public Switched Telephone Network (PSTN). The MRF provides media-related functions such as playing tones and digital announcements.

[0030] The IP multimedia services provided by IMS Network 130 include IMS voice services and / or IMS data services. Specifically, IMS voice services (also known as IMS Voice over Packet-Switched (IMSVoPS) services) can refer to IMS voice services that include voice components, such as LTE Voice over LTE (VoLTE), LTE Video over LTE (ViLTE), NR Voice over NR (VoNR), and NR Video over NR (ViNR). IMS data services (also known as PS-based IMS (IMSDoPS) services) can refer to IMS services that do not include voice components, such as IMS-based Short Message Service (SMS), Mission Critical Push To Talk (MCPTT), Mission Critical Video (MCVideo), Mission Critical Data (MCData), Rich Communication Service (RCS), XML Configuration Access Protocol (XCAP), etc.

[0031] In one embodiment, UE 110 may support one or both of IMS voice service and IMS data service of IMS network 130. Similarly, depending on the operator's service deployment scenario, mobile communication network 120 may support one or both of IMS voice service and IMS data service of IMS network 130.

[0032] According to a novel aspect, a session-based solution is provided to offer a reliable way to deliver specific application data, such as game data, VR / AR / MR data, and medical data. Specifically, regardless of whether the operator is aware of this specific data delivery scenario, UE 110 can send application data based on an RTP stream established in an IMS session (e.g., an IMSVOPS / IMSDoPS session).

[0033] According to another novel aspect, a non-session-based solution is proposed to provide a reliable way to deliver specific application data. Specifically, when the operator is unaware of this specific data delivery scenario, the UE110 can send application data in a SIP message (e.g., in an SMS message within a SIP message).

[0034] Figure 2 A block diagram illustrating UE 110 according to an embodiment of this application is provided.

[0035] like Figure 2 As shown, the UA may include a wireless transceiver 10, a controller 20, a storage device 30, a display device 40, and an input / output (I / O) device 50.

[0036] The wireless transceiver 10 can be configured to perform wireless transmission and reception to and from the wireless communication network 120. Specifically, the wireless transceiver may include a baseband processing device 11, a radio frequency (RF) device 12, and an antenna 13, wherein the antenna 13 may include an antenna array for beamforming.

[0037] The baseband processing device 11 is configured to perform baseband signal processing and control communication between the user identification card (not shown) and the RF device 12. The baseband processing device 11 may include multiple hardware components to perform baseband signal processing, including analog-to-digital conversion (ADC) / digital-to-analog conversion (DAC), gain adjustment, modulation / demodulation, encoding / decoding, etc.

[0038] RF device 12 can receive RF wireless signals via antenna 13, convert the received RF wireless signals into baseband signals, which are processed by baseband processing device 11; or RF device 12 can receive baseband signals from baseband processing device 11, convert the received baseband signals into RF wireless signals, and then transmit them via antenna 13. RF device 12 may also include multiple hardware devices to perform radio frequency conversion. For example, RF device 12 may include a mixer for multiplying the baseband signal with a carrier oscillating in the radio frequency of the supported cellular technology, wherein, depending on the RAT used, the radio frequency may be any radio frequency used in 5G (e.g., NR) systems (e.g., millimeter wave 30 GHz to 300 GHz, or 3.3 GHz to 4.9 GHz for sub-6 GHz bands) or may be 900 MHz, 2100 MHz, or 2.6 GHz used in 4G (e.g., LTE / LTE-A / TD-LTE) systems, or another radio frequency.

[0039] The controller 20 can be a general-purpose processor, a microcontroller unit (MCU), an application processor, a digital signal processor (DSP), a graphics processing unit (GPU), a holographic processing unit (HPU), a neural processing unit (NPU), etc. The controller 20 includes various circuits that provide the following functions: data processing and calculation, controlling the wireless transceiver 10 to transmit and receive data with the wireless communication network 120, enabling the storage device 30 to store or retrieve data, sending a series of frame data (e.g., represented as text messages, graphics, images, etc.) to the display device 40, and receiving input signals from or sending output signals to the I / O device 50.

[0040] Specifically, the controller 20 can coordinate the aforementioned operations of the wireless transceiver 10, storage device 30, display device 40, and I / O device 50 to perform a method for providing reliable application data transmission.

[0041] In another embodiment, the controller 20 may be integrated into the baseband processing device to serve as the baseband processor 11.

[0042] As those skilled in the art will understand, the circuitry of controller 20 typically includes transistors configured to control the operation of the circuitry in accordance with the functions and operations described herein. It will be further understood that the specific structure or interconnections of the transistors are typically determined by a compiler, such as a Register Transfer Language (RTL) compiler. An RTL compiler can be operated by a processor based on scripts that are very similar to assembly language code, to compile the scripts into the form used for the final circuit layout or fabrication. Indeed, RTL is renowned for its role and use in facilitating the design flow of electronic and digital systems.

[0043] Storage device 30 may be a non-transitory computer-readable storage medium, including a Universal Integrated Circuit Card (UICC) (e.g., a Subscriber Identity Module (SIM) or a Universal SIM (USIM) card), a memory (e.g., flash memory or non-volatile random access memory (NVRAM)), a magnetic storage device (e.g., a hard disk or magnetic tape), an optical disk, or any combination thereof, for storing data, instructions and / or applications, communication protocols, and / or program code of the methods of this application.

[0044] Display device 40 may be a liquid crystal display (LCD), a light-emitting diode (LED) display, or an electronic paper display (EPD), etc., for providing display functions. Alternatively, display device 40 may further include one or more touch sensors disposed on or below it for sensing the contact, connection, or proximity of an object (such as a finger or pen).

[0045] I / O device 50 may include one or more buttons, keyboards, mice, touchpads, cameras, microphones and / or speakers, etc., to serve as a human-machine interface (MMI) for interacting with users, such as receiving user input and outputting prompts to the user.

[0046] It should be understood that Figure 2The components described in the embodiments are for illustrative purposes only and are not intended to limit the scope of this application. For example, UE 110 may include more components, such as a power supply and / or a Global Positioning System (GPS) device, wherein the power supply may be a mobile / replaceable battery that provides power to all other components of UE 110, and the GPS device may provide location information of UE 110 for use by some location-based services or applications. Alternatively, UE 110 may include fewer components. For example, UE 110 may not include display device 40 and / or I / O device 50.

[0047] Figure 3 This is a flowchart illustrating a method for providing reliable application data transmission according to an embodiment of this application.

[0048] In this embodiment, the method is applied to and executed by a UE (e.g., UE 110) that is communicatively connected to a mobile communication network (e.g., mobile communication network 120) that supports IMS services.

[0049] First, the UE determines whether the mobile communication network supports IMS service (step S310).

[0050] In one embodiment, IMS service may refer to IMS voice service. In another embodiment, IMS service may refer to IMS data service.

[0051] Then, the UE establishes a PDN connection or PDU session with the mobile communication network for IMS services in response to the mobile communication network supporting IMS services (step S320).

[0052] In one embodiment, if the mobile communication network is a 4G network (e.g., an LTE / LTE-A / TD-LTE network), the UE establishes a PDN connection. In another embodiment, if the mobile communication network is a 5G network (e.g., an NR network), the UE establishes a PDU session.

[0053] Then, the UE sends application data in the PDN connection or PDU session (step S330).

[0054] In one embodiment, for mobile communication networks supporting IMS voice services, a session-based solution can be applied using an unaware mode, where the operator is unaware of the application data stream delivered based on existing audio / video RTP streams (i.e., conventionally defined for IMSVOPS sessions and the audio / video RTP streams used therein). Specifically, the UE can send a SIP Invitation (SIP INVITE) message including Session Description Protocol (SDP) attributes, where the SDP attributes indicate that application data is sent in a PDN connection or PDU session using audio or video RTP streams. For example, the SDP attributes may include a session name field indicating an IMS Data over Packet Switched (IMSDoPS) session, a session information field indicating the type and identifier of the application data, and a media information field indicating audio or video RTP. Alternatively, the UE can first send a SIP INVITE message to initiate a voice call session, and then send a SIP INVITE message (e.g., with the aforementioned SDP attributes) to modify the voice call session into an IMSDoPS session.

[0055] For mobile communication networks supporting IMS voice services, a session-based solution can be applied using an operator-aware mode. In this mode, the operator is aware of the application data streams delivered based on separate audio / video RTP streams (i.e., a new definition for the IMSDoPS session and the audio / video RTP streams used within it). Specifically, the UE can send a SIP INVITE message including header fields indicating whether application data is being sent using audio or video RTP streams within a PDN-connected PDU session. These header fields may include a subject indication indicating the IMSDoPS session and a reason indication indicating the type and identifier of the application data.

[0056] In another embodiment, for cases where the mobile communication network supports IMS voice service, a non-session-based solution can be applied using an operator-unknown mode, where the operator is unaware of the application data stream delivered based on the existing text RTP stream (i.e., the text RTP stream conventionally defined for text messaging and used therein). Specifically, the UE can send application data in a SIP message. For example, the application data can be sent as a plain text message (e.g., an SMS message) within the SIP message.

[0057] To further explore, in carrier-unknown mode, existing audio / video / text RTP streams can be used to send application data, and each application (e.g., each game) can use predefined configurations. With these predefined configurations, the sender and receiver know how to map SDP to the correct application, which codec to use, how much bandwidth to request, and how to encode / decode application data.

[0058] Figure 4A and 4B An example of a configuration for mapping applications to corresponding parameters is shown for an operator-unknown mode. In operator-known mode, application data is sent using a separate RTP stream, and the operator can define the codec, bandwidth, and syntax.

[0059] Figure 5 This is a message sequence diagram illustrating a session-based solution for transmitting game data using an operator-unknown mode, according to an embodiment of this application.

[0060] In this embodiment, application data specifically refers to the game data of a certain game application, but this application is not limited to this.

[0061] In step S501, user A launches the game platform application in UE 1.

[0062] In step S502, user A selects one of the games offered by the game platform application that he / she wants to play.

[0063] In step S503, user A selects another user (e.g., user B) from the contact list with whom he / she wants to play the game.

[0064] In step S504, user A initiates a game session with user B, and UE 1 sends a SIP INVITE message to UE 2 in response. Specifically, the SDP attributes in the SIP INVITE message include a session name field indicating the IMSDoPS session (in... Figure 5 The session information field (represented as "s=IMSDoPS session") indicates the type and identifier of the application data. Figure 5 This is represented as "i = game data game-ID#1234"), and a media information field indicating audio or video RTP (in... Figure 5 This is represented as "m = audio 49816 RTP / AVP 127105"). Furthermore, in the SDP attributes, the "b" parameter is used to request appropriate Quality of Service (QoS) and bandwidth based on the selected game.

[0065] Although not shown, before step S504, UE 1 may first establish a PDN connection or PDU session with a mobile communication network that supports IMS voice services.

[0066] In step S505, UE 2 responds to the SIP INVITE message by sending a response message (i.e., 180 ringing) to UE 1 indicating that the called party (i.e., user B) is being alerted.

[0067] In step S506, UE 2 further sends another response message (i.e., 200 OK) to UE 1 indicating that the call (i.e., the game session) has been answered.

[0068] In step S507, UE1 sends an acknowledgment (ACK) message to UE2 to confirm receipt of the final response (i.e., 200 OK response).

[0069] In step S508, UE 1 and UE 2 begin transmitting game data based on the audio RTP stream.

[0070] Figure 6A and 6B A message sequence diagram is shown for a session-based solution for transmitting game data using an operator-unknown mode, according to another embodiment of this application.

[0071] In this embodiment, application data specifically refers to the game data of a certain game application, but this application is not limited to this.

[0072] In step S601, user A initiates a VoLTE call with user B, and correspondingly, UE 1 sends a SIP INVITE message to UE 2. Specifically, the SDP attribute in the SIP INVITE message includes an indication of a VoLTE call (in... Figure 6A The session name field (represented as "s = VoLTE call") and the media information field indicating audio or video RTP (in...) Figure 6A This is represented as "m = audio 49816 RTP / AVP 127 105").

[0073] Although not shown, before step S601, UE 1 may first establish a PDN connection or PDU session with a mobile communication network that supports IMS voice service.

[0074] In step S602, UE 2 responds to the SIP INVITE message by sending a response message (i.e., 180 ringing) to UE 1 indicating that the called party (i.e., user B) is being alerted.

[0075] In step S603, UE 2 further sends another response message (i.e., 200 OK) to UE 1 indicating that the call has been answered.

[0076] In step S604, UE1 sends an acknowledgment (ACK) message to UE2 to confirm receipt of the final response (i.e., 200 OK response).

[0077] In step S605, UE 1 and UE 2 begin transmitting audio data based on the audio RTP stream.

[0078] During a VoLTE call, User A and User B decide to update the call to an audio plus game call. UE 1 sends a re-invitation message (Re-INVITE message) to UE 2 in response (step S606). Specifically, the Re-INVITE message is another SIP INVITE message with different SDP attributes. The SDP attributes include a session name field indicating the IMSDoPS session (in... Figure 6A The session information field (represented as "s=IMSDoPS session") indicates the type and identifier of the application data. Figure 6A This is represented as "i = game data game-ID#1234"), and a media information field indicating audio or video RTP (in... Figure 6A This is represented as "m = audio 49816 RTP / AVP 127 105"). Furthermore, in the SDP attributes, the "b" parameter is used to request appropriate QoS and bandwidth based on the selected game.

[0079] Although not shown, prior to step S606, user A or user B can open the game platform application and select the game to play and the contact to play the game with, similar to... Figure 5 Steps S501 to S503 in the embodiment.

[0080] In step S607, UE 2 responds to the SIP INVITE message by sending a response message (i.e., 180 ringing) to UE 1 indicating that the called party (i.e., user B) is being alerted.

[0081] In step S608, UE 2 further sends another response message (i.e., 200 OK) to UE 1 to indicate that the call (i.e., the game session) has been answered.

[0082] In step S609, UE1 sends an acknowledgment (ACK) message to UE2 to confirm receipt of the final response (i.e., 200 OK response).

[0083] In step S610, UE 1 and UE 2 begin transmitting audio and game data based on the audio RTP stream.

[0084] Figure 7 This is a message sequence diagram illustrating a session-based solution for transmitting game data using an operator-unknown mode, according to an embodiment of the application.

[0085] In this embodiment, application data specifically refers to AR / VR data, but this application is not limited to this.

[0086] In step S701, user A decides to initiate a video call with user B, adding AR / VR features. UE 1 sends a SIP INVITE message to UE 2 in response. Specifically, the SDP attributes in the SIP INVITE message include: a session name field indicating the IMSDoPS session (in... Figure 7 The session information field (represented as "s=IMSDoPS session") indicates the type and identifier of the application data. Figure 7 The text appears to be a mix of Chinese characters and symbols, possibly representing a speech call or audio RTP field. A direct translation wouldn't be meaningful without further context or clarification. Figure 7 The second media information field, which indicates the video RTP, is represented as "m = audio 49170RTP / AVP 0" (in the Chinese text). Figure 7 The text appears to be a mix of Chinese characters and symbols, possibly representing a video file or a third-party media information field for AR / VR applications. A direct translation wouldn't be meaningful without further context or clarification. Figure 7 This is represented as "m = application 32416udp wb" in Chinese, and media attribute fields for AR / VR applications (in...). Figure 7 This is represented as "a = orient:portrait" in Chinese. Additionally, the AR / VR media description field (m-line) can indicate whether the codec to be used is AVC / H.264, HEVC / H.265, VP8, or VP9.

[0087] Although not shown, before step S701, UE 1 may first establish a PDN connection or PDU session with a mobile communication network that supports IMS voice service.

[0088] In step S702, UE 2 responds to the SIP INVITE message by sending a response message (i.e., 180 ringing) to UE 1 indicating that the called party (i.e., user B) is being alerted.

[0089] In step S703, UE 2 further sends another response message (i.e., 200 OK) to UE 1 indicating that the call (i.e., the game session) has been answered.

[0090] In step S704, UE1 sends an acknowledgment (ACK) message to UE2 to confirm receipt of the final response (i.e., 200 OK response).

[0091] In step S705, UE 1 and UE 2 begin transmitting audio, video and AR / VR data based on audio RTP streams, video RTP streams and AR / VR applications.

[0092] Figure 8A and 8B A message sequence diagram is shown for a session-based solution for transmitting game data using a known operator pattern, according to an embodiment of this application.

[0093] In this embodiment, application data specifically refers to the game data of a certain game application, but this application is not limited to this.

[0094] In step S801, user A starts the game platform application in UE 1.

[0095] In step S802, user A selects one of the games offered by the game platform application that he / she wants to play.

[0096] In step S803, user A selects another user (e.g., user B) from the contact list with whom he / she wants to play the game.

[0097] In step S804, user A initiates a game session with user B, and UE 1 responds by sending a SIP INVITE message to UE 2 via the IMS network. Specifically, the header fields of the SIP INVITE message include: a subject indicator indicating the IMSDoPS session (in... Figure 8A The term "session" is used to indicate the type of application data and the reason for the identifier (in the context of the session: "IMSDoPS"). Figure 8A The reason is indicated as "Game Data Game-ID#1234". Once a SIP INVITE message is received, the IMS network can identify a request to deliver application data based on an audio RTP stream in an IMSDoPS session. Based on the game ID (i.e., 1234), the IMS network may need to determine the codec, bandwidth, and syntax defined by the operator for the game before forwarding the SIP INVITE message to UE 2.

[0098] Although not shown, before step S804, UE 1 may first establish a PDN connection or PDU session with a mobile communication network that supports IMS voice services.

[0099] In step S805, UE 2 responds to the SIP INVITE message by sending a response message (i.e., 180 ringing) to UE 1 via the IMS network, indicating that the called party (i.e., user B) is being alerted.

[0100] In step S806, UE 2 further sends another response message (i.e., 200 OK) to UE 1 via the IMS network, indicating that the call (i.e., the game session) has been answered.

[0101] In step S807, UE1 sends an acknowledgment (ACK) message to UE2 via the IMS network to confirm receipt of the final response (i.e., 200 OK response).

[0102] In step S808, UE 1 and UE 2 begin transmitting game data based on the audio RTP stream.

[0103] Figure 9A and 9B A message sequence diagram is shown for a non-session-based solution for transmitting game data using an operator-unknown mode, according to an embodiment of this application.

[0104] In this embodiment, application data specifically refers to the game data of a certain game application, but this application is not limited to this.

[0105] In step S901, user A starts the game platform application in UE 1.

[0106] In step S902, user A selects one of the games offered by the game platform application that he / she wants to play.

[0107] In step S903, user A selects another user (e.g., user B) from the contact list with whom he / she wants to play the game.

[0108] In step S904, user A initiates a game session with user B, and UE 1 sends a SIP message to UE 2 in response. Specifically, the SIP message includes a specific game string indicating "IMSDoPS: Not Session; Game Data: Game-ID#3456; Data: X:Y=0,1". Figure 9B For example, a specific game string can be understood as a plain text message (e.g., an SMS message) carried in a SIP message.

[0109] Although not shown, before step S904, UE 1 may first establish a PDN connection or PDU session with a mobile communication network that supports IMS data services.

[0110] In step S905, UE 2 responds to the SIP message by sending a response message (i.e., 200 OK) to UE 1.

[0111] In step S906, UE 2 further sends a SIP message to UE 1. Specifically, the content of the SIP message includes a specific game string indicating "IMSDoPS Non-Session; Game Data Game-ID#3456; Data: X:Y=0,1". Figure 9B ).

[0112] In step S907, UE 1 responds to the SIP message by sending a response message (i.e., 200 OK) to UE 2.

[0113] While this application has been described by way of example and according to preferred embodiments, it should be understood that this application is not limited thereto. Various changes and modifications can be made by those skilled in the art without departing from the scope and spirit of this application. Therefore, the scope of this application should be defined and protected by the following claims and their equivalents.

[0114] The use of ordinal terms such as "first" and "second" in claims to describe claim elements does not imply that one claim element has any priority, order of precedence, or sequence of execution of another claim, or chronological order of implementation of the method of execution. However, such ordinal terms are merely used as markers to distinguish one claim element with the same name from another element with the same name (but using ordinal numbers), thereby distinguishing claim elements.

Claims

1. A user equipment for providing reliable application data transmission, comprising: A wireless transceiver is configured to perform sending and receiving to and from mobile communication networks; as well as The controller is configured as follows: Determine whether the mobile communication network supports IP Multimedia Subsystem services; The wireless transceiver establishes a packet data network connection or protocol data unit session with the mobile communication network for the IP multimedia subsystem service, in response to the mobile communication network supporting the IP multimedia subsystem service. The wireless transceiver transmits a first session initiation protocol invitation message including session description protocol attributes, wherein the session description protocol attributes indicate that application data should be transmitted in the packet data network connection or the protocol data unit session using audio real-time transport protocol streams or video real-time transport protocol streams, wherein the session description protocol attributes include a session name field indicating a packet-switched IP Multimedia Subsystem data session and a session information field indicating the type and identifier of the application data; and The application data is transmitted via the wireless transceiver within the packet data network connection or the protocol data unit session.

2. The user equipment for providing reliable application data transmission according to claim 1, characterized in that, The IP Multimedia Subsystem service includes the IP Multimedia Subsystem Voice service.

3. The user equipment for providing reliable application data transmission according to claim 2, characterized in that, The controller is further configured to send the first session initiation protocol invitation message via the wireless transceiver to initiate a voice call session before sending the second session initiation protocol invitation message, and the second session initiation protocol invitation message is sent to modify the voice call session into a packet-switched IP Multimedia Subsystem data session.

4. The user equipment for providing reliable application data transmission according to claim 1, characterized in that, The IP Multimedia Subsystem service includes IP Multimedia Subsystem Data Service.

5. The user equipment for providing reliable application data transmission according to claim 4, characterized in that, The controller is further configured to send a session initiation protocol invitation message via the wireless transceiver, including a header field indicating that the application data is sent in the packet data network connection or the protocol data unit session using an audio real-time transport protocol stream or a video real-time transport protocol stream.

6. The user equipment for providing reliable application data transmission according to claim 5, characterized in that, The header field includes a subject indication indicating the packet-switched IP Multimedia Subsystem data session and a reason indication indicating the type and identifier of the application data.

7. The user equipment for providing reliable application data transmission according to claim 1, characterized in that, The application data includes one of the following: Game data; Virtual reality data, augmented reality data, or mixed reality data; and Medical data.

8. A method for providing reliable application data transmission, performed by a user equipment, comprising: Determine whether the mobile communication network supports IP Multimedia Subsystem services; To establish a packet data network connection or protocol data unit session with the mobile communication network for the IP multimedia subsystem service, in response to the mobile communication network supporting the IP multimedia subsystem service; Send a first session initiation protocol invitation message including session description protocol attributes, wherein the session description protocol attributes indicate that the application data is to be sent in the packet data network connection or the protocol data unit session using audio real-time transport protocol stream or video real-time transport protocol stream, wherein the session description protocol attributes include a session name field indicating a packet-switched IP Multimedia Subsystem data session and a session information field indicating the type and identifier of the application data, and The application data is sent within the packet data network connection or the protocol data unit session.

9. The method for providing reliable application data transmission according to claim 8, characterized in that, The IP Multimedia Subsystem service includes the IP Multimedia Subsystem Voice service.

10. The method for providing reliable application data transmission according to claim 9, characterized in that, Further includes: Send the first session initiation protocol invitation message before sending the second session initiation protocol invitation message to initiate a voice call session; The second session initiation protocol invitation message is sent to modify the voice call session into a packet-switched IP Multimedia Subsystem data session.

11. The method according to claim 8, characterized in that, The IP Multimedia Subsystem service includes IP Multimedia Subsystem Data Service.

12. The method for providing reliable application data transmission according to claim 11, characterized in that, Further includes: Send a Session Initiation Protocol Invitation Message including a header field, wherein the header field indicates that the application data is to be sent in the Packet Data Network Connection or the Protocol Data Unit Session using an Audio Real-Time Transport Protocol (ATTP) stream or a Video Real-Time Transport Protocol (VRT) stream.

13. The method for providing reliable application data transmission according to claim 12, characterized in that, The header field includes a subject indication indicating the packet-switched IP Multimedia Subsystem data session and a reason indication indicating the type and identifier of the application data.

14. The method for providing reliable application data transmission according to claim 8, characterized in that, The application data includes one of the following: Game data; Virtual reality data, augmented reality data, or mixed reality data; and Medical data.

Images