Method for implementing PTT voice one-key pass based on IoT-NTN system

Abstract

The application provides a method for realizing PTT voice one-key communication based on an IoT-NTN system, and relates to the technical field of communication, and comprises the following steps: configuring an anchor carrier and a non-anchor carrier in a service cell of the IoT-NTN; broadcasting multicast configuration information to a terminal through the anchor carrier, wherein the multicast configuration information comprises a group radio network temporary identifier corresponding to a group and resource scheduling information of the non-anchor carrier; when PTT voice multicast data needs to be sent, encapsulating the PTT voice multicast data into a transport block, repeatedly sending the same transport block in a plurality of continuous downlink subframes in a TTI bundling mode on the non-anchor carrier; and a terminal in an idle state listens to a physical downlink control channel on the non-anchor carrier according to the group radio network temporary identifier, receives the repeatedly sent transport block according to the resource scheduling information, and obtains the PTT voice multicast data, so that low-latency and high-efficiency PTT voice multicast reception is realized, and downlink spectrum resource occupation is reduced.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a method for implementing one-touch PTT voice communication based on an IoT-NTN system. Background Technology

[0002] Push-to-Talk (PTT), also known as one-button communication, is a half-duplex communication technology that enables real-time intercom functionality based on the Public Land Mobile Network (PLMN). Users can conduct one-to-one or one-to-many voice calls by pressing specific buttons. PTT has been applied in industries such as logistics, retail, railways, and security, and it is also a solution for emergency voice communication. In recent years, with the development of satellite communication networks, providing emergency voice services via satellite has become a widely anticipated trend.

[0003] In narrowband satellite IoT systems, existing technologies cannot support idle-state terminals to directly receive PTT voice multicast data: if point-to-point voice is used, the call setup delay is large and downlink spectrum resources are heavily occupied; if a single carrier is used to transmit broadcast multicast configuration information and service data simultaneously, it is easy to cause resource conflicts and congestion between system information and multicast data, and the terminal lacks a HARQ feedback mechanism in the idle state, making it difficult to guarantee reliable reception under wide satellite link coverage. Summary of the Invention

[0004] This invention provides a method for implementing one-click PTT voice communication based on an IoT-NTN system, which solves the defect in the prior art that it cannot directly support idle terminals to receive PTT voice multicast data.

[0005] This invention provides a method for implementing one-touch PTT voice communication based on an IoT-NTN system, comprising: In the serving cell of IoT-NTN, multiple carriers are configured, including anchor carriers and non-anchor carriers; Multicast configuration information is broadcast to the terminal via the anchor carrier. The multicast configuration information includes: a temporary identifier of the group wireless network corresponding to the group, and resource scheduling information of the non-anchor carrier. When PTT voice multicast data needs to be sent, the PTT voice multicast data is encapsulated into a transport block, and the same transport block is repeatedly sent in multiple consecutive downlink subframes using the TTI bundling method on the non-anchor carrier. A terminal in an idle state listens to the physical downlink control channel on the non-anchor carrier according to the temporary identifier of the group wireless network, receives the repeatedly transmitted transport block according to the resource scheduling information, and obtains the PTT voice multicast data.

[0006] According to the present invention, a method for implementing one-touch PTT voice communication based on an IoT-NTN system, wherein broadcasting multicast configuration information to the terminal via the anchor carrier includes: The network side transmits system information blocks through the anchor carrier, and the system information blocks carry configuration information of the single-cell multicast control channel; The terminal reads the configuration information of the single-cell multicast control channel and obtains the group radio network temporary identifier and the resource scheduling information of the non-anchor carrier from the single-cell multicast control channel.

[0007] According to the present invention, a method for implementing one-touch PTT voice communication based on an IoT-NTN system is provided, wherein the anchor carrier is used to transmit system information blocks, paging messages, and single-cell multicast control channels; and the non-anchor carrier is used to carry single-cell multicast service channels.

[0008] According to the present invention, a method for implementing one-touch PTT voice communication based on an IoT-NTN system is provided, which employs TTI bundling on the non-anchor carrier to repeatedly transmit the same transport block in multiple consecutive downlink subframes, including: The number of consecutive downlink subframes configured on the network side is a pre-configured fixed value; The same transport block is repeatedly sent according to the fixed value.

[0009] The method for implementing one-touch PTT voice communication based on an IoT-NTN system provided by the present invention further includes: The network side dynamically configures the number of consecutive downlink subframes based on the link budget and broadcasts the multicast configuration information to the terminal.

[0010] According to the present invention, a method for implementing one-touch PTT voice communication based on an IoT-NTN system is provided, wherein receiving the repeatedly transmitted transmission block according to the resource scheduling information includes: The terminal accumulates energy to merge and decode the same transport block received in multiple consecutive downlink subframes, compensating for the decoding performance loss when the terminal does not send HARQ acknowledgment information back to the network side.

[0011] According to the present invention, a method for implementing one-touch PTT voice communication based on an IoT-NTN system is provided, wherein the step of monitoring the physical downlink control channel on the non-anchor carrier includes: The network side uses the group radio network temporary identifier to scramble the narrowband physical downlink control channel; The terminal uses the pre-stored temporary identifier of the group radio network to descramble the narrowband physical downlink control channel and obtains the scheduling information of the multicast data carried on the non-anchor carrier.

[0012] The method for implementing one-touch PTT voice communication based on an IoT-NTN system provided by the present invention further includes: The MCPTT server receives voice packets sent by the speaking terminal via uplink unicast. The MCPTT server sends the voice packet to BM-SC; The BM-SC distributes the voice packets to the IoT-NTN satellite base station via the MBMS-GW; The satellite-borne base station uses the voice packet as PTT voice multicast data and performs the repeated transmission on the non-anchor carrier.

[0013] The method for implementing one-touch PTT voice communication based on an IoT-NTN system provided by the present invention further includes: The speaking terminal sends a speaking right request carrying the RTCP protocol via uplink unicast bearer; After determining the priority, the MCPTT server returns a speaking right grant message to the speaking terminal via uplink unicast. The MCPTT server sends a notification to other terminals in the group that their speaking rights have been taken, causing those other terminals to enter listening mode.

[0014] According to the present invention, a method for realizing one-click PTT voice communication based on an IoT-NTN system is provided, wherein the terminal is a satellite Internet of Things terminal that supports the IoT-NTN protocol, including a handheld terminal, a vehicle-mounted terminal, a ship-mounted terminal, or an airborne terminal; The idle terminal periodically listens to the physical downlink control channel when no RRC connection is established, and after receiving the repeatedly transmitted transport block, it remains in the idle state and does not switch to the connected state.

[0015] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method for one-touch PTT voice communication based on the IoT-NTN system as described above.

[0016] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method for one-click PTT voice communication based on the IoT-NTN system as described above.

[0017] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the method for one-click PTT voice communication based on the IoT-NTN system as described above.

[0018] Beneficial effects This invention provides a method for implementing one-touch PTT voice communication based on an IoT-NTN system. By configuring anchor carriers and non-anchor carriers for separate transmission, and using anchor carriers to broadcast multicast configuration information, resource conflicts between system information and multicast service data are avoided. At the same time, TTI bundling is used on the downlink non-anchor carriers to repeatedly transmit the same transport block, so that idle terminals can listen for and receive multicast data based on the temporary identifier of the group wireless network without entering the connected state. Furthermore, energy accumulation overcomes link loss in the non-feedback environment. Thus, while ensuring wide coverage and reliability, low-latency and high-efficiency PTT voice multicast reception is achieved, significantly reducing downlink spectrum resource consumption. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the method for implementing one-touch PTT voice communication based on an IoT-NTN system provided by the present invention. Figure 2 This is a schematic diagram of the narrowband satellite Internet of Things (PTT) system provided by the present invention; Figure 3 This is a schematic diagram of the system for implementing one-touch PTT voice communication based on the IoT-NTN system provided by the present invention; Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0022] Figure 1 This is a flowchart illustrating the method for implementing one-touch PTT voice communication based on an IoT-NTN system provided by the present invention. Figure 2 This is a schematic diagram of the narrowband satellite Internet of Things (PTT) system provided by the present invention.

[0023] like Figure 1As shown, the overall architecture of the narrowband satellite IoT PTT system to which this invention applies includes: a ground terminal, an IoT-NTN base station, a ground gateway station (IP secure routing), an operation and maintenance entity, a home subscriber server, a mobility management entity, a service gateway, a service open module, a packet gateway, an application server, a policy and billing unit, a multicast gateway, a broadcast service center, and an intercom application server. The IoT-NTN system must support single-cell point-to-multipoint SC-PTM characteristics and multi-carrier configuration, dividing the serving cell into anchor carriers and non-anchor carriers, and supporting the transmission time interval binding TTI bundling feature at the downlink physical layer. The ground terminal must be able to listen to multicast data in idle mode without establishing an RRC connection.

[0024] The core principle is that after the operation and maintenance entity completes the system parameter configuration, the IoT-NTN base station is configured with a separate transmission architecture for anchor carriers and non-anchor carriers in the serving cell. The home subscriber server stores the subscription data of all groups and terminals. The mobility management entity is responsible for terminal location registration and mobility management. The service gateway and packet gateway are responsible for data routing and forwarding within the core network. The policy and charging unit ensures the QoS priority and charging control of PTT voice services. The service open module provides system capability open interfaces. Multicast configuration information, including the group radio network temporary identifier corresponding to the group and resource scheduling information for non-anchor carriers, is broadcast to ground terminals via anchor carriers to avoid resource conflicts between system information and multicast service data. When PTT voice multicast data needs to be transmitted, the intercom application server receives the voice data from the speaking terminal, forwards it to the broadcast service center, and distributes it to each IoT-NTN base station via the multicast gateway. The application server uniformly schedules the transmission, using TTI bundling on the non-anchor carriers to repeatedly transmit the same transport block in multiple consecutive downlink subframes. Ground terminals in idle state access the network through ground gateway stations. Based on the temporary identifier of the group radio network, they listen to the physical downlink control channel on non-anchor carriers. According to resource scheduling information, they receive repeatedly transmitted transport blocks. Through energy accumulation, merging, and decoding, they compensate for the performance loss without HARQ feedback. Ultimately, idle terminals can receive PTT voice multicast data with low latency without establishing a radio resource control (RRC) connection.

[0025] like Figure 2 As shown, the present invention provides a method for implementing one-touch PTT voice communication based on an IoT-NTN system, comprising: 201. Configure multiple carriers in the serving cell of IoT-NTN. The multiple carriers include anchor carriers and non-anchor carriers.

[0026] Specifically, within a single IoT-NTN service cell covered by the satellite-based base station, at least one anchor carrier and at least one non-anchor carrier are configured simultaneously. The anchor carrier serves as the reference carrier for the entire cell, acting as the sole reference for all terminals' initial access, camping, and synchronization. The non-anchor carrier serves as a dedicated multicast service carrier, specifically used for transmitting PTT voice multicast data. By separating system control information and multicast service data for transmission on different carriers, resource contention issues between system information broadcasting, paging messages, and multicast service data, common in single-carrier configurations, are fundamentally avoided. Furthermore, by increasing the number of non-anchor carriers, more concurrent PTT multicast services can be supported.

[0027] 202. Broadcast multicast configuration information to the terminal via the anchor carrier. The multicast configuration information includes: the temporary identifier of the group wireless network corresponding to the group, and the resource scheduling information of the non-anchor carrier.

[0028] Specifically, the satellite-based base station periodically broadcasts system messages and multicast-related control information on the anchor carrier. All terminals within the cell, regardless of whether they are in idle or connected state, can receive these broadcast messages normally. By parsing the broadcast messages, the terminal obtains the unique Group Radio Network Temporary Identifier (G-RNTI) corresponding to the PTT group it is interested in, as well as resource scheduling information such as the frequency and time slot of the non-anchor carrier used for the group's multicast data. This allows the terminal to obtain all the necessary configuration information for the multicast service in advance before initiating or receiving a PTT call, eliminating the need for complex resource negotiation and configuration during call setup and significantly reducing call setup latency.

[0029] 203. When PTT voice multicast data needs to be sent, the PTT voice multicast data is encapsulated into a transport block, and the same transport block is repeatedly sent in multiple consecutive downlink subframes using the TTI bundling method on a non-anchor carrier.

[0030] Specifically, when the critical task one-click application server, i.e., the MCPTT server, needs to send voice data to a specific PTT group, it forwards the voice data packets to the corresponding satellite-based base station. The satellite-based base station encapsulates the voice data into transport blocks (TBs) conforming to the IoT-NTN protocol specification. Then, on the non-anchor carrier corresponding to that group, it uses transmission time interval binding (TTI) bundling technology to repeatedly transmit the same transport block TB multiple times in consecutive downlink subframes. By repeatedly transmitting the same transport block TB, the terminal can improve the received signal-to-noise ratio through energy accumulation, solving the problems of high satellite link propagation loss and poor reception reliability caused by the inability of idle-state terminals to send hybrid automatic repeat request (HARQ) acknowledgment information. This ensures that users at the cell edge can also receive PTT voice data normally.

[0031] 204. When a terminal is in an idle state, it listens to the physical downlink control channel on a non-anchor carrier according to the temporary identifier of the group wireless network, receives repeatedly transmitted transport blocks according to resource scheduling information, and obtains PTT voice multicast data.

[0032] Specifically, terminals in idle state do not need to establish a Radio Resource Control (RRC) connection. They only need to periodically listen to the Physical Downlink Control Channel (PDCCH) on the corresponding non-anchor carrier based on the pre-acquired G-RNTI. When downlink control information (DCI) scrambled with the G-RNTI is detected, the terminal will receive repeatedly transmitted transport blocks (TBs) in subsequent downlink subframes according to the resource location indicated in the DCI. These repeated TBs are then merged and decoded to finally reconstruct the PTT voice data. The terminal remains in idle state throughout the entire reception process, without going through the complex processes of RRC connection establishment, authentication, and bearer establishment, significantly reducing the mouth-to-ear latency of PTT voice and truly achieving the instant intercom effect of one person speaking while the whole group listens.

[0033] Furthermore, based on the above embodiments, this embodiment broadcasts multicast configuration information to the terminal via anchor carrier, including: the network side transmits system information blocks via anchor carrier, the system information blocks carrying configuration information of the single-cell multicast control channel; the terminal reads the configuration information of the single-cell multicast control channel and obtains the group wireless network temporary identifier and the resource scheduling information of the non-anchor carrier from the single-cell multicast control channel.

[0034] Specifically, the satellite-based base station transmits a system information block (SIB20-NB) on the anchor carrier. This SIB contains all configuration information for the single-cell multicast control channel (SC-MCCH), including its transmission period, time slot location, and modulation / coding scheme. All terminals within the cell, after camping on the anchor carrier, automatically read the SIB20-NB to obtain the SC-MCCH configuration information. Based on the SC-MCCH configuration information indicated in the SIB20-NB, the terminal receives data from the SC-MCCH at the corresponding time position. The SC-MCCH carries a list of all available PTT multicast groups within the current cell, along with detailed information such as the G-RNTI identifier for each group, the non-anchor carrier information used, and the multicast service scheduling period. The terminal extracts and saves the relevant configuration information for groups of interest based on its subscription information and user selection. Through a two-level broadcast mechanism using SIB20-NB and the single-cell multicast control channel SC-MCCH, efficient and reliable distribution of multicast configuration information is achieved. Terminals can obtain the latest multicast service information at any time in idle state without needing to provide feedback to the network.

[0035] Furthermore, based on the above embodiments, in this embodiment, the anchor carrier is used to transmit system information blocks, paging messages, and single-cell multicast control channels; the non-anchor carrier is used to carry single-cell multicast service channels.

[0036] Specifically, the anchor carrier undertakes all control plane functions within the cell, including: broadcasting the System Master Information Block (MIB) and all System Information Blocks (SIBs) for initial terminal access and system synchronization; sending paging messages to notify terminals of incoming calls or system message updates; and transmitting the Single Cell Multicast Control Channel (SC-MCCH) to broadcast configuration information for all PTT multicast groups. All terminals camp on the anchor carrier in idle mode, only needing to listen to the anchor carrier's control channel to obtain all necessary system information and paging messages.

[0037] Non-anchor carriers do not carry any system control information; all resources are used to transmit PTT voice multicast service data on the single-cell multicast service channel SC-MTCH. Each PTT multicast group corresponds to an independent single-cell multicast service channel SC-MTCH. Different single-cell multicast service channels SC-MTCH can be mapped to different non-anchor carriers, or they can be mapped to the same non-anchor carrier in a time-division multiplexing manner to achieve load balancing of multicast services.

[0038] Anchor carriers and non-anchor carriers achieve complete separation between the control plane and the user plane. Anchor carriers focus on the transmission of control information, ensuring the stability and reliability of the system, while non-anchor carriers focus on the transmission of multicast services, maximizing the utilization of spectrum resources and supporting more concurrent multicast services.

[0039] Furthermore, based on the above embodiments, this embodiment adopts the TTIbundling method on non-anchor carriers to repeatedly transmit the same transport block in multiple consecutive downlink subframes, including: configuring the number of multiple consecutive downlink subframes on the network side to a pre-configured fixed value; and repeatedly transmitting the same transport block according to the fixed value.

[0040] Specifically, the network side pre-configures a fixed transmission time interval (TTI) binding length for each PTT multicast group based on the typical propagation characteristics and coverage requirements of the satellite link. This TTI bundling length is the number of downlink subframes that are continuously and repeatedly transmitted in a Transport Block (TB). Commonly used pre-configured values ​​include 4, 8, 16, or 32. The larger the value, the more times the data is transmitted, resulting in a higher signal-to-noise ratio and stronger reliability at the terminal, but also consuming more spectrum resources.

[0041] When transmitting multicast data, the satellite-based base station strictly adheres to pre-configured fixed values, repeatedly transmitting the same Transport Block (TB) in a corresponding number of consecutive downlink subframes. The Downlink Control Information (DCI) masked by the Group Radio Network Temporary Identifier (G-RNTI) only needs to indicate the start position once. The User Equipment (UE) automatically receives and merges the data continuously according to the configured bundling length, without needing to send separate scheduling information for each repeated subframe.

[0042] By using a pre-configured fixed transmission time interval to bind the TTI bundling length, the terminal's processing flow is simplified. The terminal only needs to automatically receive the corresponding number of subframes continuously starting from the starting subframe according to the pre-saved bundling length. There is no need to parse the scheduling information of each subframe in real time, which reduces the complexity and power consumption of the terminal.

[0043] Furthermore, based on the above embodiments, this embodiment also includes: the network side dynamically configures the number of consecutive downlink subframes according to the link budget, and broadcasts the configuration information to the terminal through multicast.

[0044] Specifically, the network side can monitor changes in satellite link quality in real time and dynamically adjust the TTI bundling length for each PTT multicast group based on the current link budget. When link quality is good, the number of repetitions is reduced to save spectrum resources; when link quality is poor, the number of repetitions is increased to ensure reception reliability. The network side updates the adjusted TTI bundling length to the corresponding multicast configuration information and broadcasts it to all terminals within the group via the single-cell multicast control channel (SC-MCCH). After receiving the updated configuration information, the terminal automatically receives subsequent multicast data according to the new bundling length, adapting to different satellite link environments and maximizing spectrum resource utilization while ensuring reception reliability, thereby improving the overall system capacity.

[0045] Furthermore, based on the above embodiments, this embodiment receives repeatedly transmitted transport blocks according to resource scheduling information, including: the terminal accumulates energy to merge and decode the same transport block received in multiple consecutive downlink subframes, compensating for the decoding performance loss when the terminal does not send HARQ confirmation information back to the network side.

[0046] Specifically, since terminals in idle state can only hear but not speak, they cannot send Hybrid Automatic Repeat Request (HARQ) confirmation messages or Channel Quality Indicator (CQI) messages to the network side. Therefore, the network side cannot improve link quality through retransmission mechanisms. Thus, after receiving multiple duplicate Transport Blocks (TBs), the terminal performs energy accumulation and merging of these TB signals, essentially superimposing the signal energy received in each subframe to improve the overall received signal-to-noise ratio (SNR). The terminal decodes the merged signal. If decoding is successful, it reconstructs the PTT voice data; if decoding fails, due to the lack of a retransmission mechanism, the terminal discards the TB and continues receiving the next TB. This energy accumulation and merging decoding at the terminal side effectively compensates for link loss in the idle, feedback-free environment, ensuring reliable PTT voice reception under wide satellite link coverage. Even terminals at the cell edge can obtain clear voice quality.

[0047] Furthermore, based on the above embodiments, this embodiment monitors the physical downlink control channel on a non-anchor carrier, including: the network side scrambling the narrowband physical downlink control channel using a group radio network temporary identifier; and the terminal descrambling the narrowband physical downlink control channel using a pre-stored group radio network temporary identifier to obtain scheduling information for multicast data carried on the non-anchor carrier.

[0048] Specifically, when a satellite-based base station transmits scheduling information for a specific PTT group, it uses the group's unique G-RNTI to scramble the downlink control information (DCI) on the narrowband physical downlink control channel (NPDCCH). Different groups use different G-RNTIs for scrambling, ensuring that each terminal can only receive scheduling information from its own group. In idle mode, the terminal periodically listens to the NPDCCH on non-anchor carriers and descrambles the received NPDCCH data using its pre-stored G-RNTIs for its target groups. If descrambling is successful, it indicates that the DCI is scheduling information for its own group, and the terminal parses the DCI content to obtain the resource location and transmission parameters of the multicast data on the NPDSCH. If descrambling fails, it indicates that the DCI is intended for another group, and the terminal ignores the DCI and continues listening to subsequent NPDCCH subframes. By employing the G-RNTI scrambling and descrambling mechanism, precise addressing of multicast services is achieved. Terminals only receive scheduling information and service data from their own groups, avoiding the power consumption waste and processing burden caused by receiving irrelevant data. Furthermore, since idle-state terminals already need to periodically listen to the Physical Downlink Control Channel (PDCCH) of the anchor carrier to receive paging messages, they only need to pay extra attention to the scheduling of the corresponding G-RNTI on non-anchor carriers during non-paging times, without significantly increasing power consumption.

[0049] Furthermore, based on the above embodiments, this embodiment also includes: the MCPTT server receiving voice packets sent by the speaking terminal via uplink unicast bearer; the MCPTT server sending the voice packets to BM-SC; BM-SC distributing the voice packets to the IoT-NTN satellite base station via MBMS-GW; and the satellite base station using the voice packets as PTT voice multicast data and performing repeated transmission on non-anchor carriers.

[0050] Specifically, once a terminal gains the right to speak, it encodes the collected voice signal into voice packets in Real-Time Transport Protocol (RTP) format and sends them to the MCPTT application server via a dedicated uplink unicast bearer. The uplink unicast bearer is a dedicated point-to-point bearer established between the terminal and the network side, ensuring reliable transmission and low latency of voice data.

[0051] After receiving a voice packet from a speaking terminal, the Mission-Critical One-Click Application Server (MCPTT) identifies the PTT group to which the voice packet belongs and then forwards the voice packet to the Broadcast Multicast Service Center (BM-SC) responsible for that group. The BM-SC is the core control node for the broadcast multicast service, responsible for managing multicast sessions, distributing content, and synchronizing it.

[0052] The Broadcast Multicast Service Center (BM-SC) sends voice packets to the Multimedia Broadcast Multicast Service Gateway (MBMS-GW), which is responsible for copying and distributing the voice packets to the satellite-based base stations where all members of the PTT group are located. If group members are distributed within the coverage area of ​​multiple satellite-based base stations, the MBMS-GW will send the voice packets to all relevant satellite-based base stations simultaneously.

[0053] After receiving the voice packet, the satellite base station encapsulates it into a transport block (TB) and then, according to the transmission time interval binding TTI bundling method described in the previous embodiment, repeatedly transmits it to all terminals in the group on the corresponding non-anchor carrier.

[0054] By adopting an uplink unicast and downlink multicast transmission mode, the reliability of uplink unicast is utilized to ensure accurate verification and authentication of the speaker's identity, while the efficiency of downlink multicast is utilized. A voice data only needs to be sent once on the downlink to be received by all group members, which greatly saves satellite downlink spectrum resources.

[0055] Furthermore, based on the above embodiments, this embodiment also includes: the speaking terminal sending a speaking right request carrying the RTCP protocol via an uplink unicast bearer; the MCPTT server, after determining the priority, returning a speaking right grant message to the speaking terminal via an uplink unicast bearer; and the MCPTT server sending a notification that the speaking right has been occupied to other terminals in the group, causing other terminals to enter listening mode.

[0056] Specifically, when a user presses the PTT button on the terminal to speak, the terminal generates a Floor Request message in Real-Time Transmission Control Protocol (RTCP) format and sends it to the critical task push-to-talk application server MCPTT via uplink unicast. This request message contains the identity of the speaking terminal, its group identifier, and priority information.

[0057] When the MCPTT application server receives a request to speak, it checks if any other members are currently speaking in the group. If not, the server determines the priority of the requesting terminal, granting speaking rights to the higher-priority request. Once approved, the server sends a "Floor Granted" message to the requesting terminal, notifying it that it can begin speaking.

[0058] When granting speaking rights to a specific terminal, the MCPTT application server sends a Floor Taken notification to all other terminals in the group. Upon receiving this notification, other terminals automatically enter listening mode and disable their local PTT buttons to prevent conflicts caused by multiple users speaking simultaneously.

[0059] When a speaker releases the PTT button, the terminal sends a "Floor Release" message to the MCPTT application server. Upon receiving this message, the server releases the speaking right and sends a "Floor Idle" notification to all terminals in the group, allowing other members to request to speak. If no member requests speaking right within a certain period, the server sends a SIP BYE message or triggers a timeout mechanism, automatically closing the multicast session.

[0060] By using a talk control mechanism based on the Real-time Transmission Control Protocol (RTCP), the orderliness of half-duplex PTT communication is ensured, avoiding voice conflicts caused by multiple users speaking at the same time. It also supports priority scheduling, which can meet the needs of key users to speak first in emergency communication scenarios.

[0061] Furthermore, based on the above embodiments, in this embodiment the terminal is a satellite Internet of Things terminal that supports the IoT-NTN protocol, including a handheld terminal, a vehicle-mounted terminal, a ship-mounted terminal, or an airborne terminal; the idle terminal periodically listens to the physical downlink control channel when no RRC connection is established, and after receiving repeatedly transmitted transport blocks, it remains in the idle state and does not switch to the connected state.

[0062] Specifically, this application applies to all satellite IoT terminals conforming to the 3GPP IoT-NTN standard, covering consumer handheld terminals and various industry application terminals, capable of meeting the voice communication needs of different industry scenarios such as logistics, retail, railways, security, and emergency rescue. Throughout the entire process of receiving PTT voice multicast data, the terminal remains in the Radio Resource Control (RRC)_IDLE idle state, requiring no RRC connection with the network side and no uplink data transmission. The terminal only needs to periodically listen to the Physical Downlink Control Channel (PDCCH) to receive multicast scheduling information and voice data, and remains idle after reception. This significantly reduces terminal power consumption and extends standby time, which is particularly important for handheld terminals with limited battery capacity and unattended industry terminals. Furthermore, since no RRC connection needs to be established, the PTT voice reception latency is further shortened, improving the user's intercom experience.

[0063] The following describes the system for implementing one-click PTT voice communication based on the IoT-NTN system provided by the present invention. The system for implementing one-click PTT voice communication based on the IoT-NTN system described below can be referred to in correspondence with the method for implementing one-click PTT voice communication based on the IoT-NTN system described above.

[0064] Figure 3 This is a schematic diagram of the system for implementing one-button PTT voice communication based on the IoT-NTN system provided by the present invention.

[0065] like Figure 3 As shown in the figure, this embodiment provides a system for one-click PTT voice communication based on an IoT-NTN system, including: Configuration module 301 is used to configure multiple carriers in the serving cell of IoT-NTN, wherein the multiple carriers include anchor carriers and non-anchor carriers; The broadcast module 302 is used to broadcast multicast configuration information to the terminal through the anchor carrier. The multicast configuration information includes: a temporary identifier of the group wireless network corresponding to the group, and resource scheduling information of the non-anchor carrier. The delivery module 303 is used to encapsulate the PTT voice multicast data into a transport block when there is PTT voice multicast data to be delivered, and to repeatedly send the same transport block in multiple consecutive downlink subframes using the TTI bundling method on the non-anchor carrier. The receiving module 304 is used for a terminal in an idle state to listen to the physical downlink control channel on the non-anchor carrier according to the temporary identifier of the group wireless network, receive the repeatedly transmitted transport block according to the resource scheduling information, and obtain the PTT voice multicast data.

[0066] Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention.

[0067] like Figure 4 As shown, the electronic device may include: a processor 410, a communications interface 420, a memory 430, and a communications bus 440, wherein the processor 410, the communications interface 420, and the memory 430 communicate with each other through the communications bus 440. The processor 410 can call logic instructions in the memory 430 to execute a method for implementing one-touch PTT voice communication based on an IoT-NTN system. This method includes: configuring multiple carriers in the serving cell of the IoT-NTN, the multiple carriers including anchor carriers and non-anchor carriers; broadcasting multicast configuration information to the terminal via the anchor carriers, the multicast configuration information including: a group radio network temporary identifier corresponding to the group, and resource scheduling information of the non-anchor carriers; when PTT voice multicast data needs to be sent, encapsulating the PTT voice multicast data into a transport block, and repeatedly transmitting the same transport block in multiple consecutive downlink subframes using TTI bundling on the non-anchor carriers; the terminal in an idle state, according to the group radio network temporary identifier, listens to the physical downlink control channel on the non-anchor carriers, receives the repeatedly transmitted transport block according to the resource scheduling information, and obtains the PTT voice multicast data.

[0068] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0069] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the method for implementing one-touch PTT voice communication based on the IoT-NTN system provided by the above methods. The method includes: configuring multiple carriers in the serving cell of IoT-NTN, the multiple carriers including anchor carriers and non-anchor carriers; broadcasting multicast configuration information to the terminal through the anchor carrier, the multicast configuration information including: a group radio network temporary identifier corresponding to the group, and resource scheduling information of the non-anchor carrier; when there is PTT voice multicast data to be sent, encapsulating the PTT voice multicast data into a transport block, and repeatedly sending the same transport block in multiple consecutive downlink subframes using TTI bundling on the non-anchor carrier; the terminal in the idle state listening to the physical downlink control channel on the non-anchor carrier according to the group radio network temporary identifier, receiving the repeatedly sent transport block according to the resource scheduling information, and obtaining the PTT voice multicast data.

[0070] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements a method for implementing one-touch PTT voice communication based on an IoT-NTN system, as provided by the methods described above. This method includes: configuring multiple carriers in the serving cell of the IoT-NTN, the multiple carriers including anchor carriers and non-anchor carriers; broadcasting multicast configuration information to a terminal via the anchor carriers, the multicast configuration information including: a group radio network temporary identifier corresponding to the group, and resource scheduling information of the non-anchor carriers; when PTT voice multicast data needs to be sent, encapsulating the PTT voice multicast data into a transport block, and repeatedly transmitting the same transport block in multiple consecutive downlink subframes using TTIbundling on the non-anchor carriers; and a terminal in an idle state listening to the physical downlink control channel on the non-anchor carriers according to the group radio network temporary identifier, receiving the repeatedly transmitted transport block according to the resource scheduling information, and obtaining the PTT voice multicast data.

[0071] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0072] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0073] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for implementing one-touch PTT voice communication based on an IoT-NTN system, characterized in that, include: In the serving cell of IoT-NTN, multiple carriers are configured, including anchor carriers and non-anchor carriers; Multicast configuration information is broadcast to the terminal via the anchor carrier. The multicast configuration information includes: a temporary identifier of the group wireless network corresponding to the group, and resource scheduling information of the non-anchor carrier. When PTT voice multicast data needs to be sent, the PTT voice multicast data is encapsulated into a transport block, and the same transport block is repeatedly sent in multiple consecutive downlink subframes using the TTI bundling method on the non-anchor carrier. A terminal in an idle state listens to the physical downlink control channel on the non-anchor carrier according to the temporary identifier of the group wireless network, receives the repeatedly transmitted transport block according to the resource scheduling information, and obtains the PTT voice multicast data.

2. The method for implementing one-click PTT voice communication based on an IoT-NTN system according to claim 1, characterized in that, The broadcasting of multicast configuration information to the terminal via the anchor carrier includes: The network side transmits system information blocks through the anchor carrier, and the system information blocks carry configuration information of the single-cell multicast control channel; The terminal reads the configuration information of the single-cell multicast control channel and obtains the group radio network temporary identifier and the resource scheduling information of the non-anchor carrier from the single-cell multicast control channel.

3. The method for implementing one-touch PTT voice communication based on an IoT-NTN system according to claim 1, characterized in that, The anchor carrier is used to transmit system information blocks, paging messages, and single-cell multicast control channels; the non-anchor carrier is used to carry single-cell multicast service channels.

4. The method for implementing one-touch PTT voice communication based on an IoT-NTN system according to claim 1, characterized in that, The step of repeatedly transmitting the same transport block in multiple consecutive downlink subframes using TTI bundling on the non-anchor carrier includes: The number of consecutive downlink subframes configured on the network side is a pre-configured fixed value; The same transport block is repeatedly sent according to the fixed value.

5. The method for implementing one-touch PTT voice communication based on an IoT-NTN system according to claim 4, characterized in that, Also includes: The network side dynamically configures the number of consecutive downlink subframes based on the link budget and broadcasts the multicast configuration information to the terminal.

6. The method for implementing one-touch PTT voice communication based on an IoT-NTN system according to claim 1, characterized in that, Receiving the repeatedly transmitted transport block according to the resource scheduling information includes: The terminal accumulates energy to merge and decode the same transport block received in multiple consecutive downlink subframes, compensating for the decoding performance loss when the terminal does not send HARQ acknowledgment information back to the network side.

7. The method for implementing one-touch PTT voice communication based on an IoT-NTN system according to claim 6, characterized in that, The step of listening to the physical downlink control channel on the non-anchor carrier includes: The network side uses the group radio network temporary identifier to scramble the narrowband physical downlink control channel; The terminal uses the pre-stored temporary identifier of the group radio network to descramble the narrowband physical downlink control channel and obtains the scheduling information of the multicast data carried on the non-anchor carrier.

8. The method for implementing one-touch PTT voice communication based on an IoT-NTN system according to claim 1, characterized in that, Also includes: The MCPTT server receives voice packets sent by the speaking terminal via uplink unicast. The MCPTT server sends the voice packet to BM-SC; The BM-SC distributes the voice packets to the IoT-NTN satellite base station via the MBMS-GW; The satellite-borne base station uses the voice packet as PTT voice multicast data and performs the repeated transmission on the non-anchor carrier.

9. The method for implementing one-touch PTT voice communication based on an IoT-NTN system according to claim 8, characterized in that, Also includes: The speaking terminal sends a speaking right request carrying the RTCP protocol via uplink unicast bearer; After determining the priority, the MCPTT server returns a speaking right grant message to the speaking terminal via uplink unicast. The MCPTT server sends a notification to other terminals in the group that their speaking rights have been taken, causing those other terminals to enter listening mode.

10. The method for implementing one-touch PTT voice communication based on an IoT-NTN system according to any one of claims 1-9, characterized in that, The terminal is a satellite Internet of Things terminal that supports the IoT-NTN protocol, including handheld terminals, vehicle-mounted terminals, shipborne terminals, or airborne terminals. The idle terminal periodically listens to the physical downlink control channel when no RRC connection is established, and after receiving the repeatedly transmitted transport block, it remains in the idle state and does not switch to the connected state.

Images