EP3895394A1 - Régulation de congestions de communications de groupe (gc) - Google Patents

Régulation de congestions de communications de groupe (gc)

Info

Publication number
EP3895394A1
EP3895394A1 EP18826238.0A EP18826238A EP3895394A1 EP 3895394 A1 EP3895394 A1 EP 3895394A1 EP 18826238 A EP18826238 A EP 18826238A EP 3895394 A1 EP3895394 A1 EP 3895394A1
Authority
EP
European Patent Office
Prior art keywords
server
group call
group
satisfied
condition
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP18826238.0A
Other languages
German (de)
English (en)
Inventor
Magnus TRÄNK
Joakim ÅKESSON
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of EP3895394A1 publication Critical patent/EP3895394A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/08—User group management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/10—Push-to-Talk [PTT] or Push-On-Call services

Definitions

  • GC group communication
  • Mission Critical (MC) radio communication services are essential for the work performed by public safety users (e.g. police, fire brigade).
  • An MC radio communication service requires preferential handling of user communications compared to normal radio communication services. For example, an MC call for an emergency situation should be prioritized when the radio network handling the MC call is facing a congestion situation.
  • a commonly used communication method for MC calls is Group Communication
  • GC GC
  • PTT Push to Talk
  • GC can be provided using different transmission modes.
  • GC is that the same information is delivered to multiple users. These users may be located at different locations. If a large group of these users are located within the same area, then multicast or broadcast based transmission using, for example, Multicast-Broadcast Multimedia Services (MBMS), can be an efficient way to provide the same information to the group of users who are located in the same area.
  • MBMS can be used in a transmission mode known as Multicast- broadcast single-frequency network (MBSFN).
  • MBSFN Multicast- broadcast single-frequency network
  • MBSFN Multicast- broadcast single-frequency network
  • unicast transmission mode may be preferable.
  • unicast transmission mode there is a single logical connection for one or more users involved in a group call and each of one or more users’ logical connections can be optimized for the services that the user is using at the moment as well as adapted for the specific user’s current radio conditions.
  • Whether or not to use multicast transmission as a transmission mode for a GC call is an important and difficult decision from a radio efficiency point of view.
  • One aspect of using MBMS in a 3 GPP based network is that the start-up procedure for an MBMS bearer is typically long (e.g., > 30s) while a PTT call setup time is required to be very short (e.g., ⁇ 300 ms).
  • a normal PTT call on average lasts less than 30 seconds.
  • the use of multicast transmission for a PTT call requires an MBMS bearer be started before the PTT call is started, and should only be used when it is efficient (e.g., when there are sufficient number of users involved in the call).
  • radio utilization depends highly on the current radio condition as well as the current requested capacity. However, it can be very difficult to estimate the current load of the radio network. One reason for this is that users are moving around causing the radio situation to constantly change. Another reason is that radio resources are shared across many users and services with different characteristics and needs. If an objective is to achieve a high utilization of radio resources, this objective can be hard to achieve when a radio capacity reservation and queuing mechanism is employed on the network. In certain deployments of multicast in a 3 GPP network, the capacity is static, predefined and dedicated for a certain service which makes queueing for radio network resources possible.
  • a GC server is disclosed herein wherein, in one embodiment, the GC server initiates the activation of a multicast bearer (e.g., MBMS bearer) in a certain area when a congestion indication is received for the area, and sets-up GC calls in confirmed mode over unicast transmission during the time period required for activating the multicast bearer.
  • a multicast bearer e.g., MBMS bearer
  • the GC server can notify GC clients in the area that the multicast bearer is available and the GC server uses the multicast bearer to transmit call data.
  • the GC server initiates the activation of the multicast bearer for an area as a result of receiving a group call request and determining that a condition is satisfied (e.g., congestion is present in the area and a sufficient number of GC clients are located in the area).
  • a condition e.g., congestion is present in the area and a sufficient number of GC clients are located in the area.
  • this disclosure proposes, in one embodiment, to initiate the activation of a multicast bearer (e.g., MBMS bearer) in a certain area as soon as a congestion indication is received for the area, and to set-up GC calls in confirmed mode in unicast transmission (i.e., GC clients need to acknowledge the GC call setup request to establish GC calls) during the time period required for activating the multicast bearer.
  • a multicast bearer e.g., MBMS bearer
  • the congestion indication could be of several types (e.g., notification from the radio network, notification from wireless devices that the latency increases, awareness of the GC traffic situation in the specific area, etc.).
  • the method includes a GC server obtaining network congestion information for a particular area, the network congestion information indicating an amount of network congestion.
  • the method also includes the GC server determining whether a condition is satisfied, wherein determining whether the condition is satisfied comprises determining whether the indicated amount of congestion satisfies a first threshold.
  • the method also includes as a result of determining that the condition is satisfied, the GC server initiating an activation of a multicast bearer.
  • the method also includes the GC server receiving a group call request for a group call.
  • the method also includes the GC server setting up the group call by using a GC confirmed mode when unicast bearers are used in the particular area.
  • the method also includes the GC server obtaining location data, wherein the location data identifies a location of each GC client included in a group of GC clients and determining whether the condition is satisfied further comprises using the location data to determine whether the condition is satisfied.
  • the method further includes based on the obtained location data, the GC server determining the total number of the GC clients included in the group of GC clients that are either currently located within the particular area or likely to be located within the particular area within a time period and using the location data to determine whether the condition is satisfied comprises determining whether the determined total number of GC clients satisfies a second threshold.
  • the GC server receives the group call request after determining that the condition is satisfied, wherein the group call request was transmitted by a first GC client and the group call request comprises a group identifier that identifies a group of GC clients.
  • setting up the group call using the GC confirmed mode comprises the GC server determining that a second GC client is a member of the group of GC clients, the GC server determining whether the multicast bearer satisfies a criteria, and as a result of determining that the second GC client is a member of the group of GC clients and that the multicast bearer does not satisfy the criteria, the GC server transmitting to the second GC client a group call request comprising an indicator indicating that acknowledgement is required for the group call.
  • the method further comprises after transmitting the group call request to the second GC client, the GC server receiving from a service center a message providing an indication that the multicast bearer is ready to be used, the GC server announcing the multicast bearer to the second GC client, and the GC server receiving a listening report from the second GC client.
  • initiating the activation of the multicast bearer comprises transmitting an activate bearer request message to a service center and the activate bearer request message comprises information indicating a broadcast area. In some embodiments, the particular area is within the broadcast area. [0017] In some embodiments, the method further comprises receiving the network congestion information from a base station and/or a user equipment, and/or determining the network congestion information based on historical data.
  • the network congestion information comprises information indicating a packet loss rate, a packet queue length, a shortage of radio control resources, a shortage of media plane resource, decreased retainability, and/or decreased accessibility.
  • the group call request does not indicate that the GC confirmed mode is required.
  • the method comprises a GC server obtaining network congestion
  • the method also includes the GC server receiving a group call request for a group call, the group call request comprising a group identifier that identifies a group of GC clients.
  • the method also includes the GC server determining whether a condition is satisfied, wherein determining whether the condition is satisfied comprises determining whether the indicated amount of network congestion satisfies a threshold.
  • the method also includes as a result of receiving the group call request and determining that the condition is satisfied, the GC server setting up the group call in a GC confirmed mode.
  • the group call request was transmitted by a first GC client, and setting up the group call in the GC confirmed mode comprises the GC server determining that a second GC client is a member of the group of GC clients and the GC server transmitting to the second GC client a group call request comprising an indicator indicating that
  • the method further comprises the GC server initiating an activation of a multicast bearer before receiving the group call request, wherein determining whether the condition is satisfied further comprises determining whether the multicast bearer is available.
  • the method further comprises the GC server initiating an activation of a multicast bearer as a result of receiving the group call request and determining that the condition is satisfied.
  • the embodiments of the this disclosure provide an advantage of providing reliable network resource management in a congestion situation and handling the delay of the multicast bearer startup in a predictable and understandable way for end-users.
  • FIG. 1 illustrates a group communication system according to some embodiments.
  • FIG. 2 is a message flow diagram illustrating exchanges of messages among a plurality of clients, network nodes, and a network server.
  • FIG. 3 is a flow chart illustrating a process according to some embodiments.
  • FIG. 4 is a flow chart illustrating a process according to some embodiments.
  • FIG. 5 is a block diagram of an apparatus according to some embodiments.
  • FIG. 1 illustrates a Group Communication (GC) system 100 according to one embodiment.
  • System 100 includes GC clients 101-103 in communication with a radio access point 104 (e.g., a 3GPP 4G base station (eNB) or a 3GPP 5G base station (gNB)) of a radio access network (RAN).
  • a radio access point 104 e.g., a 3GPP 4G base station (eNB) or a 3GPP 5G base station (gNB)
  • RAN radio access network
  • Each on of GC clients 101-103 is a wireless communication device (a.k.a.,“user equipment” (UE)) capable of wireless communication with a radio access point.
  • a GC client could be a Mission Critical (MC) service client (see 3GPP TS 23.280) or an Mission Critical Push To Talk (MCPTT) client (see 3GPP TS 23.379).
  • the radio access point 104 in this example is connected to a core network 110 (e.g.,
  • System 100 also includes a GC server 105 (e.g. an MCPTT server according to 3GPP TS 23.379, an MC service server according to 3GPP TS 23.280, a GC Application Server (AS) according to 3GPP TS 23.468).
  • a GC server 105 e.g. an MCPTT server according to 3GPP TS 23.379, an MC service server according to 3GPP TS 23.280, a GC Application Server (AS) according to 3GPP TS 23.468.
  • a unicast transmission mode for a GC call can be an efficient mode, particularly when the number of GC clients involved in the GC call is low, because the unicast radio bearer for each GC client can be adjusted to be optimal for the GC client’s current radio condition.
  • multicast transmission may be more efficient because, instead of having a different unicast bearer for each GC client, the GC clients can utilize a single multicast bearer when receiving GC.
  • GC in confirmed mode For some types of GC calls for a group of clients it is important that all GC clients in the group acknowledge the group call setup request prior to the start of the call. This is sometimes referred to as“GC in confirmed mode.” In the MCPTT standard this is referred to as “MCPTT Group Call setup request requires acknowledgement,” and is defined in 3GPP TS 22.179. GC in confirmed mode may also be limited to the GC clients in a specific area. Due to the fact that an acknowledgement must be received from each of the GC clients in the group before the call can commence, GC in confirmed mode has a negative impact on the call setup time. Hence, GC in confirmed mode is often avoided when there is a large number of GC clients in the group.
  • the radio network situation can be difficult to predict. If there is any reason to presume that the radio network resources are starved it can be advantageous to use multicast transmission.
  • This disclosure proposes to use GC in confirmed mode during the initiation of a multicast bearer (e.g., MBMS bearer) in the area where congestion is detected or presumed. This will give a reliable and predictable user experience in group communication in radio congestion situations.
  • the use of GC in confirmed mode can be limited to the users in a specific area, e.g. a congested area.
  • FIG. 2 is a message flow diagram illustrating an embodiment. As shown in FIG.
  • GC server 105 may receive: a message 202 transmitted by radio access point 104, a message 204 transmitted by GC client 101, and/or a message 206 transmitted by one or more of GC clients 102 and 103. While only three GC clients (i.e., GC clients 101, 102, and 103) are shown on FIG. 2, this is for illustration purpose only and does not limit the embodiments of the present disclosure in any way.
  • Each of messages 202, 204, and 206 may contain network congestion information for a particular area. The particular area may correspond to an area covered by a particular radio network or a particular radio base station (e.g., a cell or a set of cells).
  • Messages 202, 204, and 206 may be transmitted to GC server 105 periodically and/or sporadically (e.g., in response to a request from GC server 105).
  • radio access point 104 may transmit message 202 to GC server 105.
  • Radio access point 104 may monitor performance indicators (e.g., a shortage of radio control resources, a shortage of media plane resource, decreased retainability, and/or decreased accessibility) captured by a radio network performance management system and/or other operation and management system, and transmit message 202 based on the captured performance indicators.
  • the value of the captured performance may provide an indication of network usage in a particular area.
  • Message 202 transmitted based on the value of the captured performance may include network congestion information providing an indication of an amount of network congestion in the particular area.
  • the network congestion information may provide an indication of whether a network of the particular area is congested or not.
  • Message 202 may be transmitted over PCRF via Rx interface according to 3 GPP TS 29.214. Where the PCRF is the Policy Control and Rule Function of a 3 GPP based network.
  • GC client 101 may send message 204 towards GC server 105.
  • Message 204 may include quality reports (e.g., quality measurements (QM) such as a packet latency, a packet queue length, and/or a packet drop rate) of a radio network to which GC client 101 is connected.
  • QM quality measurements
  • An increased packet latency, an increased packet queue length, and/or an increased packet drop rate may indicate an increased congestion of the radio network.
  • Message 204 including the quality reports may contain network congestion information providing an indication of an amount of network congestion in a particular area.
  • the network congestion information may provide an indication of whether a network of the particular area is congested or not.
  • the quality reports may be included in Real Time Control Protocol (RTCP) reports.
  • RTCP Real Time Control Protocol
  • FIG. 2 shows that GC server 105 receives message 202 before it receives messages 204 and 206, messages 202, 204, and 206 can be received at GC server 105 in any order.
  • Network congestion information for a particular area may also be provided to GC server 105 by GC clients transmitting to GC server 105 messages acknowledging the receipt of call set up requests.
  • each of GC clients 101-103 may send a message acknowledging the receipt of a call set up request and including a timestamp of when the call set up request was received.
  • a significant variation on the timestamps among GC clients 101-103 may indicate a highly loaded radio access network.
  • messages 202 and 204 may provide real-time network congestion information (i.e., providing network congestion information based on real-time data) for a particular area.
  • GC server 105 may not receive any real-time congestion information for the particular area.
  • GC server 105 obtains historical data regarding network congestion in the particular area.
  • GC server 105 may include a storage medium storing information regarding network congestion of the particular area and a corresponding time period or a corresponding timestamp during/at which the information is obtained.
  • the data stored in the storage medium of GC server 105 may provide that network congestion occurred in a particular area between 5 pm and 7 pm every Friday for the past 3 months.
  • GC server 105 may predict that the particular area will be network congested between 5 pm and 7 pm this coming Friday. GC server 105 may predict such an event based on a model that has been generated through a machine learning process (e.g., a supervised learning model).
  • a machine learning process e.g., a supervised learning model
  • GC server 105 obtain network congestion information for a particular area, and in the embodiments of this disclosure any one or combination of such different ways can be used.
  • GC server 105 After GC server 105 obtains network congestion information for a particular area,
  • GC server determines in action 208 whether to initiate the activation of a multicast bearer in the particular area (which in this case is an MBMS bearer) based on the received network congestion information. For example, GC server 105 may compare an amount of network congestion indicated by the received network congestion information with a threshold to determine whether congestion is present in a particular area. As another example, may determine whether congestion is present in a particular area based on the value of a congestion flag included in message 202 (e.g. if the congestion flag is sent to a logical value of TRUE, then GC server 105 will determine that congestion is present in a cell served by eNB 104).
  • a congestion flag included in message 202 e.g. if the congestion flag is sent to a logical value of TRUE, then GC server 105 will determine that congestion is present in a cell served by eNB 104.
  • GC server 105 initiates the activation of the MBMS bearer. In another embodiment, GC server 105 initiates the activation of the MBMS bearer in a particular area as a result of i) determining that a congestion situation is present in the particular area and ii) determining that at least a threshold number of GC clients is located (or is likely to be located) in the particular area. Thus, GC server 105 may obtain location data for GC clients.
  • GC clients may send to GC server 105 location data identifying its location, and, based on the location data, GC server 105 determines a total number of GC clients currently located in the particular area or likely to be located in the particular area within a certain time period.
  • GC server 105 may compare the total number with a threshold and determine to initiate an activation of the MBMS bearer if the total number is greater than or equal to the threshold and congestion is detected or anticipated. Therefore, even if a particular area is network congested, GC server 105 may not initiate to activate an MBMS bearer if only a few GC clients is located in the particular area.
  • GC sever 105 initiates the activation of the MBMS bearer by sending to BM-SC 106 message 210 requesting MBMS bearer activation.
  • GC server 105 may receive from GC client 101 a message 212 (e.g., a“Group call request” as described in 3GPP TS 23.379 v 16.0.0 (see, e.g., sections 10.6.2.2.7 and 10.6.2.3.1.1 of the TS)) requesting to set up a group call.
  • the Group call request from GC client 101 may include an implicit floor request.
  • Message 212 may include a group identifier identifying a group of GC clients, some of which may be located in an area covered by the MBMS bearer.
  • the group of GC clients includes GC clients 102 and 103, which are in the area covered by the MBMS bearer.
  • GC server 105 determines whether the MBMS bearer is available (i.e., able to be used) for the requested group call.
  • GC server 105 determines that the MBMS bearer is available and it is efficient to use the MBMS bearer (e.g., the MBMS bearer is not filled up), GC server 105 starts the group call in the multicast transmission mode. However, if GC server 105 determines that the MBMS bearer is not available or it is not efficient to use the MBMS bearer (e.g., not yet fully activated or announced to the GC clients), GC server 105 initiates the group call in the unicast transmission mode as described below.
  • GC server 105 may receive from GC client 101 message 212 before GC server 105 receives network congestion information. In those situations, in response to receiving the request to setup the group call, GC server 105 may determine whether congestion exists in the particular area. For example, GC server 105 identifies a group of GC clients based on a group identifier included in the request, and send to one or more of GC clients (e.g., GC clients 101, 102 and 103) belong to the group and/or node 104 messages requesting them to transmit to GC server 105 network congestion information. After GC server 105 receives network congestion information, GC server 105 may determine whether to activate the MBMS bearer based on the received network congestion information.
  • GC server 105 may determine whether to activate the MBMS bearer based on the received network congestion information.
  • GC server 105 determines that the MBMS is available, GC server 105 initiates a group call in the multicast transmission mode. However, if GC server 105 determines that the MBMS bearer is not yet become available or is filled-up (e.g., at or near capacity), GC server 105 may initiate the group call in the unicast transmission mode.
  • GC server 105 transmits a message 214 (e.g., a Group call request or“Group call connect” as described in 3GPP TS 23.379 v 16.0.0 (see, e.g., sections 10.6.2.2.9 and 10.6.2.3.1.1 of the TS)) to GC clients 102 and 103.
  • the message 214 may correspond to a Floor Taken message.
  • Message 214 may include an indicator indicating that acknowledgement is required for the group call.
  • GC server 105 may send to GC client 101 a message 218 (e.g., a Floor Granted message) providing an indication that the group call may commence.
  • GC server 105 may also send to GC clients 102 and 103 a message 220 (e.g., Floor Taken) providing an indication that there is an established group call among the members of the group.
  • GC server 105 may receive a message indicating that the MBMS bearer is available. For example, GC server 105 may receive from BM-SC message 222 indicating that the bearer is available and/or GC server 105 may receive from a GC client a message 223 (e.g., a listening report) indicating that the bearer is available. As a result of receiving a message indicating that the MBMS bearer is available, GC server 105 may send to each of the GC clients a message 224 announcing the multicast bearer.
  • the GC clients which receive message 224 may optionally send to GC server 105 a message acknowledging the receipt of message 224 (a.k.a. MBMS listening report). After the GC server announces the availability of the MBMS bearer, and the GC server may use the MBMS bearer to transmit call data.
  • FIG. 3 is a flowchart illustrating a process 300 according to an embodiment.
  • Process 300 may begin in step s302.
  • Step s302 comprises GC server 105 (e.g., an MCPTT server) obtaining network congestion information for a particular area (e.g., a cell, a set of cells, etc.).
  • the GC server obtains the network congestion information by receiving network congestion information transmitted by one or more GC clients and/or more base stations (see, e.g., messages 202, 204, and 206 shown in FIG. 2).
  • the obtained network congestion information indicates an amount of network congestion (e.g., the network congestion information may be information that indicates an increased latency, a packet queue length, a packet drop rate or it may be a congestion flag set to a particular value that indicates that at least a certain level of congestion is present in the area.
  • the network congestion information may be information that indicates an increased latency, a packet queue length, a packet drop rate or it may be a congestion flag set to a particular value that indicates that at least a certain level of congestion is present in the area.
  • Step s304 comprises the GC server determining whether a condition is satisfied, wherein determining whether the condition is satisfied comprises determining whether the indicated amount of congestion satisfies a first threshold (e.g. is greater than or is equal to the threshold). This is similar to step 208 described above.
  • Step s306 comprises the GC server, as a result of determining that the condition is satisfied, initiating an activation of a multicast bearer.
  • initiating the activation of the multicast bearer comprises the GC server transmitting message 210 (e.g., an activate bearer request, Activate MBMS Bearer Request) to a service center (e.g., BM-SC 106), where the message 210 comprises information indicating a broadcast area (e.g., a list of MBMS Service Area Identities, or a list of cell IDs, or both), and the particular area is within the broadcast area.
  • Step s308 comprises the GC server receiving a group call request for a group call
  • the group call request transmitted by the GC client does not indicate that the GC confirmed mode is required.
  • Step s310 comprises the GC server setting up the group call by using a GC confirmed mode when unicast bearers are used in the particular area (e.g., when the bearer is not yet available or the bearer does not have enough available bandwidth to handle the group call or that there are only few GC clients involved in the group call which makes the use of multicast not efficient).
  • process 300 further includes the GC server obtaining location data, wherein the location data identifies a location of each GC client included in a group of GC clients, wherein determining whether the condition is satisfied further comprises using the location data to determine whether the condition is satisfied.
  • the GC server based on the obtained location data, determines the total number of the GC clients included in the group of GC clients that are either currently located within the particular area or likely to be located within the particular area within a time period, and the step of using the location data to determine whether the condition is satisfied comprises determining whether the determined total number of GC clients satisfies a second threshold.
  • the GC server receives the group call request after the GC server determines that the condition is satisfied, the group call request was transmitted by a first GC client (e.g., GC client 101), the group call request comprises a group identifier that identifies a group of GC clients (e.g., GC client 102 and GC client 103).
  • a first GC client e.g., GC client 101
  • the group call request comprises a group identifier that identifies a group of GC clients (e.g., GC client 102 and GC client 103).
  • setting up the group call using the GC confirmed mode comprises: (1) the GC server determining that a second GC client is a member of the group of GC clients; (2) the GC server determining that the multicast bearer satisfies a criteria (e.g., the bearer is available and is efficient to use); and (3) as a result of determining that the second GC client is a member of the group of GC clients and that the multicast bearer does not satisfy the criteria, the GC server transmitting to the second GC client a group call request comprising an indicator indicating that acknowledgement is required for the group call.
  • a criteria e.g., the bearer is available and is efficient to use
  • the GC server after transmitting the group call request to the second GC client, the GC server (1) receives a message (e.g., message 222 or 223) providing an indication that the multicast bearer is available, (2) announces the multicast bearer to the second GC client, and (3) receives a listening report from the second GC client.
  • the GC server may receive an acknowledgement transmitted by the second GC client.
  • the call may start, otherwise, if not all required acknowledgements (ACKs) are received within the specific time period, then the GC server notifies the first GC client (i.e., the GC client that initiated the call) that not all of the required ACKs have been received, and the first GC client can then decide whether or not to set-up the call anyway with knowledge that not all user have acknowledged the call setup.
  • ACKs required acknowledgements
  • the step of obtaining the network congestion information comprises the GC server receiving the network congestion information from a base station and/or a user equipment (UE), and/or the GC server determining the network congestion information based on historical data.
  • UE user equipment
  • FIG. 4 is a flowchart illustrating a process 400 according to an embodiment.
  • Process 400 may begin in step s402.
  • Step s402 comprises the GC server obtaining network congestion information for a particular area (e.g., a cell, a set of cells, etc.), the network congestion information indicating an amount of network congestion.
  • a particular area e.g., a cell, a set of cells, etc.
  • the network congestion information indicating an amount of network congestion.
  • One example of performing step s402 is/are step(s) 202, 204 and/or 206 in Fig. 2.
  • Step s404 comprises the GC server receiving a group call request for a group call (e.g., receiving message 212), the group call request comprising a group identifier that identifies a group of GC clients.
  • Step s406 comprises the GC server determining whether a condition is satisfied, wherein determining whether the condition is satisfied comprises determining whether the indicated amount of network congestion satisfies a threshold.
  • Step s408 comprises the GC server setting up the group call in a GC confirmed mode as a result of receiving the group call request and determining that the condition is satisfied. For example, in step s408, GC server transmits message 214 to GC clients 102 and 103.
  • the group call request was transmitted by a first GC client
  • the GC server determining that a second GC client is a member of the group of GC clients (e.g., the GC server determines all of the members of the Group and determines that the second GC client is one of the members); and the GC server transmitting to the second GC client a group call request comprising an indicator indicating that acknowledgement is required for the group call (the GC server transmits a group call request to each of the GC clients that are included in the group and the group call request transmitted to a GC client that is included in the group will include the indicator indicating that acknowledgement is required for the group call if the GC client is in the particular area).
  • process 400 further includes the GC server initiating an activation of a multicast bearer before receiving the group call request (e.g., transmitting message 210), wherein determining whether the condition is satisfied further comprises determining whether the multicast bearer is available.
  • the GC server initiates the activation of the multicast bearer as a result of receiving the group call request and determining that the condition is satisfied.
  • the group call is started (granted) once an acknowledgement is received from the at least one second GC client in the group of GC clients.
  • FIG. 5 is a block diagram of an apparatus 500, according to some embodiments, for implementing GC server 105.
  • apparatus 500 may comprise: processing circuitry (PC) 502, which may include one or more processors (P) 555 (e.g., a general purpose microprocessor and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed; a network interface 548 comprising a transmitter (Tx) 545 and a receiver (Rx) 547 for enabling apparatus 500 to transmit data to and receive data from other nodes connected to a network 110 (e.g., an Internet Protocol (IP) network) to which network interface 548 is connected; and a local storage unit (a.k.a.,“data storage system”) 508, which may include one or more non-volatile storage devices and/or one or more volatile
  • IP Internet Protocol
  • CRM 543 comprising computer readable instructions (CRI) 544.
  • CRM 542 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like.
  • the CRI 544 of computer program 543 is configured such that when executed by PC 502, the CRI causes apparatus 500 to perform steps described herein (e.g., steps described herein with reference to the flow charts).
  • apparatus 500 may be configured to perform steps described herein without the need for code. That is, for example, PC 502 may consist merely of one or more ASICs.
  • the features of the embodiments described herein may be implemented in hardware and/or software.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Emergency Management (AREA)
  • Environmental & Geological Engineering (AREA)
  • Public Health (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un serveur de GC, qui lance l'activation d'un support de multidiffusion (par ex., un support de MBMS) dans une certaine zone, dès qu'une indication de congestion est reçue pour la zone, et qui établit des appels de GC en mode confirmé pendant la durée requise, pour activer le support de multidiffusion. Lorsque le support de multidiffusion devient disponible, le serveur de GC peut notifier à des clients de GC de la zone que le support de multidiffusion est disponible et utiliser le support de multidiffusion pour transmettre des données d'appel.
EP18826238.0A 2018-12-13 2018-12-13 Régulation de congestions de communications de groupe (gc) Withdrawn EP3895394A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2018/084748 WO2020119903A1 (fr) 2018-12-13 2018-12-13 Régulation de congestions de communications de groupe (gc)

Publications (1)

Publication Number Publication Date
EP3895394A1 true EP3895394A1 (fr) 2021-10-20

Family

ID=64899275

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18826238.0A Withdrawn EP3895394A1 (fr) 2018-12-13 2018-12-13 Régulation de congestions de communications de groupe (gc)

Country Status (2)

Country Link
EP (1) EP3895394A1 (fr)
WO (1) WO2020119903A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110134919A1 (en) * 2009-12-04 2011-06-09 Motorola, Inc. Method and system for selectable reliable multicast delivery of data using a presence service
US8817684B2 (en) * 2010-12-17 2014-08-26 Verizon Patent And Licensing Inc. Adaptive mobile multicasting for wireless networks
EP2856655B1 (fr) * 2012-05-24 2018-05-02 Hughes Network Systems, LLC Système et procédé d'utilisation efficace de ressources radio pour des services de messagerie vocale instantanée dans des systèmes de communications mobiles sans fil

Also Published As

Publication number Publication date
WO2020119903A1 (fr) 2020-06-18

Similar Documents

Publication Publication Date Title
CN110049450B (zh) 单小区的点对多点传输的方法
US10560876B2 (en) Method and device for group communication, having robust mobility
RU2361373C2 (ru) Способ и устройство для обеспечения качества услуги связи для мобильного терминала
JP6639673B2 (ja) ピアツーピアデータ伝送方法、装置及びシステム
EP1626591A1 (fr) Synchronisation d'un service push-to-talk dans un système de communication sans fil
US11930391B2 (en) Wireless communications apparatus and methods
US11337040B2 (en) Broadcast bearer management method and device thereof
WO2017134578A1 (fr) Réduction de latence pour des éléments de communication
US20180041353A1 (en) Systems and methods for establishing and using multimedia broadcast multicast services transport bearers
US11251981B2 (en) Communication method and apparatus
CN110679163B (zh) 在任务关键数据通信系统中发送和接收数据的方法和装置
US11611465B2 (en) Service interruption reporting
US9843456B2 (en) Feedback based adaptation of multicast transmission offset
KR20210127978A (ko) Mbms 다중 레벨 베어러 품질 표시자에 기초한 동적 mbms/유니캐스트 베어러 확립
WO2020119903A1 (fr) Régulation de congestions de communications de groupe (gc)
CN117336896A (zh) 会话管理方法及装置、设备、存储介质
US10356676B2 (en) Resource switching method, apparatus, and system
CA2576532C (fr) Methode indiquant un canal pour envoyer une demande d'acces a une liaison montante, et systeme a commutation automatique de canaux
JP6672460B2 (ja) グループ通信システムにおけるページング
US20240187915A1 (en) Wireless communications apparatus and methods
CN118044233A (zh) 用于通知事件增强的网络节点和其中的方法
OA19957A (en) Resource allocation for group communication in a network.
JP2014003634A (ja) 局所情報サービス

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210615

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20220111