WO2018127176A1 - Mobile communications system - Google Patents

Mobile communications system Download PDF

Info

Publication number
WO2018127176A1
WO2018127176A1 PCT/CN2018/071779 CN2018071779W WO2018127176A1 WO 2018127176 A1 WO2018127176 A1 WO 2018127176A1 CN 2018071779 W CN2018071779 W CN 2018071779W WO 2018127176 A1 WO2018127176 A1 WO 2018127176A1
Authority
WO
WIPO (PCT)
Prior art keywords
communications
request
time
stations
floor
Prior art date
Application number
PCT/CN2018/071779
Other languages
English (en)
French (fr)
Inventor
Christopher E J. KILGOUR
Mark W. Rayne
Original Assignee
Hytera Communications Corporation Limited
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 Hytera Communications Corporation Limited filed Critical Hytera Communications Corporation Limited
Priority to CN201880000297.8A priority Critical patent/CN108541381B/zh
Publication of WO2018127176A1 publication Critical patent/WO2018127176A1/en

Links

Images

Classifications

    • 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

  • the present invention relates to mobile communications systems, and in particular to methods for group communications in digital mobile radio communications systems.
  • Many mobile communications systems support group communications, wherein transmissions are shared between a group of plural communications stations.
  • An individual communications station of the group can request permission to transmit to the other members of the group, e.g. by a user pushing a button on the communications station.
  • LTE Long Term Evolution
  • LMR Land Mobile Radio
  • TETRA TErrestrial Trunked Radio
  • DMR Digital Mobile Radio
  • UHF Ultra High Frequency
  • VHF Very High Frequency
  • LTE has evolved, e.g. in the form of LTE-Advanced and LTE-Advanced Pro, and continues to evolve with on-going work to define “5G” which will incorporate earlier LTE forms as well as interconnection and interworking with other systems.
  • a method of operating a communications system comprising:
  • a communications station of the communications system transmitting a request for permission to transmit to one or more communications stations of a set of plural communications stations of the communications system;
  • the communications system using the information when determining whether and/or when the request for permission for the communications station to transmit should be granted.
  • a communications system comprising:
  • the communications system is configured, when a communications station transmits a request for permission to transmit to one or more communications stations of a set of plural communications stations, to associate with the request information indicating the time at which the request was made;
  • the communications system is configured to use the information when determining whether and/or when the request for permission for the communications station to transmit should be granted.
  • the present invention facilitates improved group communications in communications systems.
  • a communications station e.g. of a set (e.g. group) of plural communications stations, wishes to transmit to (e.g. to send transmissions (communications) to) one or more (other) communications stations of the set
  • the communications station transmits a request for permission to send such transmissions, e.g. a so-called “floor request” .
  • information indicating the time at which the request was made e.g. a “time-stamp”
  • the system determines whether or not and/or when permission should be granted for the communications station to transmit, e.g. to the one or more (other) communications stations of the set, using the time-indicating information.
  • the time-indicating information may be (and preferably is) used to determine which of the communications stations should be granted permission to transmit to the set (and correspondingly which of the communications stations should be denied permission, or granted permission to transmit to the set at a later time, or otherwise) .
  • the time-indicating information (e.g. time-stamp) may be (and preferably is) used by the communications system to “calibrate” its decision making process.
  • the Applicants have recognised that the delay time between a communications station transmitting a transmission request (e.g. floor request) and the part (e.g. server) of the system that determines whether and/or when the request should be granted receiving the request, can be significantly different from one communications station to the next. For example, this may be the case between communications stations of different interconnected or interworking communications systems or otherwise.
  • the Applicants have furthermore recognised that this can mean that some communications stations of the system can be more likely to be granted permission to transmit to the set, e.g. compared to other communications stations of the system (and vice versa) , and furthermore that this can degrade the overall performance of the system.
  • associating with a transmission request information indicating the time at which the request was made, and then using the time-indicating information when determining whether and/or when the request should be granted in the manner of the present invention can allow the system to take the varying time delays into account, e.g. in order to appropriately “calibrate” its decision making process.
  • the present invention provides an improved mobile communications system.
  • the communications system of the present invention may comprise any suitable communications system, such as for example, any one of: a 5G communications system, a 4G communications system, a Long Term Evolution (LTE) communications system such as an LTE Advanced communications system or an LTE Advanced Pro communications system, a GSM communications system, a UMTS communications system, or a (digital or analogue) Land Mobile Radio (LMR) (or Private Mobile Radio (PMR) ) communications system such as, for example, a TErrestrial Trunked Radio (TETRA) communications system, a TETRAPOL communications system, a Project 25 (P. 25) communications system, a Digital Mobile Radio (DMR) communications system, an Ultra High Frequency (UHF) analogue radio communications system or a Very High Frequency (VHF) analogue radio communications system.
  • LTE Long Term Evolution
  • LMR Long Term Evolution
  • PMR Private Mobile Radio
  • DMR Digital Mobile Radio
  • UHF Ultra High Frequency
  • VHF Very High Frequency
  • the techniques of the present invention are particularly (but not exclusively) useful in arrangements where the communications system comprises two (or more) interconnected or interworking communications system.
  • the techniques of the present invention are also particularly useful in arrangements where the communications system comprises two (or more) linked, interconnected or interworking communications subsystems, e.g. where the delay time between a communications station transmitting a transmission request (e.g. floor request) and the part (e.g. server) of the system that determines whether and/or when the request should be granted receiving the request is (substantially) different between at least some of the communications stations, e.g. and in particular between communications stations of the different linked, interconnected or interworking systems or subsystems.
  • the communications system comprises two or more linked, interconnected or interworking communications systems or subsystems.
  • the communications system comprises two or more interconnected or interworking communications systems.
  • a method of operating a system that comprises two or more interconnected or interworking communications systems comprising:
  • a communications station of the system transmitting a request for permission to transmit to one or more communications stations of a set of plural communications stations of the system;
  • the system using the information when determining whether and/or when the request for permission for the communications station to transmit should be granted.
  • a system comprising:
  • system is configured, when a communications station transmits a request for permission to transmit to one or more communications stations of a set of plural communications stations, to associate with the request information indicating the time at which the request was made;
  • system is configured to use the information when determining whether and/or when the request for permission for the communications station to transmit should be granted.
  • the system may comprise any two (or more) interconnected or interworking communications systems, e.g. (at least) a first communications system and a second interconnected or interworking communications system.
  • the communications system may additionally comprise one or more further interconnected or interworking communications systems.
  • the two (or more) interconnected or interworking communications systems may be the same type of interconnected communications system or may be different types of interworking communications system.
  • Each of the two (or more) interconnected or interworking communications systems may comprise, for example, one of: a5G communications system, a4G communications system, a Long Term Evolution (LTE) communications system such as an LTE Advanced communications system or an LTE Advanced Pro communications system, a GSM communications system, a UMTS communications system, or a (digital or analogue) Land Mobile Radio (LMR) (or Private Mobile Radio (PMR) ) communications system such as, for example, a TErrestrial Trunked Radio (TETRA) communications system, a TETRAPOL communications system, a Project 25 (P. 25) communications system, aDigital Mobile Radio (DMR) communications system, an Ultra High Frequency (UHF) analogue radio communications system or a Very High Frequency (VHF) analogue radio communications system.
  • LTE Long Term Evolution
  • LMR Long Term Evolution
  • PMR Private Mobile Radio
  • TETRA TErrestrial Trunked Radio
  • P. 25 Digital Mobile Radio
  • the system comprises two (or more) interconnected 5G or LTE communications systems.
  • the system may comprise a 5G or LTE communications system interworking with one or more Land Mobile Radio (LMR) (or Private Mobile Radio (PMR) ) communications systems such as (but not limited to) a TETRA, TETRAPOL, P. 25, DMR, UHF, and/or VHF communications system.
  • LMR Land Mobile Radio
  • PMR Private Mobile Radio
  • the communications system of the present invention preferably comprises the appropriate system infrastructure, including for example, all of the necessary system infrastructure for the communications system (in an embodiment for each of the two (or more) interconnected or interworking communications systems) , together with a plurality of communications stations.
  • one or more or each communication system may comprise any one or more or each of: a (fixed) communications network, a gateway, an inter-system interface (ISI) , one or more Application Servers (e.g. a Switching and Management Infrastructure (SwMI) ) , one or more base stations, one or more communications stations, etc.
  • ISI inter-system interface
  • SwMI Switching and Management Infrastructure
  • one or more or each communication system may comprise one or more portable cells, e.g. gateway cells.
  • the communications system in question will preferably comprise the appropriate system infrastructure in respect of the one or more portable cells, including for example, one or more or each of: a portable base station, an additional communications station connected to the portable base station, an offload gateway, etc.
  • One or more or each communication system may further comprise one or more relay nodes, and/or one or more repeater nodes, e.g. which may take the form of one or more communications stations of the communication system being operable to relay transmissions from another communications station, e.g. to the system infrastructure of the communication system in question.
  • relay nodes and/or one or more repeater nodes, e.g. which may take the form of one or more communications stations of the communication system being operable to relay transmissions from another communications station, e.g. to the system infrastructure of the communication system in question.
  • the two (or more) interconnected or interworking communications systems may be interconnected or configured for interworking in any suitable manner.
  • an interconnection function e.g. server
  • an interconnection function is preferably provided, e.g. as part of the system infrastructure of the overall system, that is preferably configured to allow interchange of signalling and media between the two (or more) interconnected communications systems.
  • an interworking function e.g. server
  • IWF interworking function
  • the system of the present invention preferably also comprises group communications control circuitry for facilitating and controlling group communications between the various communications stations of the system.
  • the system may comprise, for example, one or more group communications servers, such as one or more Push-to-Talk (PTT) servers, e.g. Mission Critical Push-to-Talk (MCPTT) server, which may be configured to facilitate group communications between the various communications stations of the system.
  • PTT Push-to-Talk
  • MCPTT Mission Critical Push-to-Talk
  • the or each communications system may comprise its own such group communications control circuitry (e.g. server) , or group communications control circuitry (e.g. a single server) may be shared between two (or more) of the interconnected or interworking communications systems.
  • group communications control circuitry e.g. a single server
  • a “primary” group communications server is provided as part of the system infrastructure of one (e.g. 5G) of the two or more communications systems, which is operable to control group communications between the various communications stations of the two (or more) communications systems.
  • the system of the present invention preferably also comprises request determining control circuitry for determining whether (or not) and/or when requests for permission for a communications station to transmit to the set of plural communications stations should be granted.
  • the request determining control circuitry may have any suitable form, and may be arranged in any suitable part of the overall system.
  • the request determining control circuitry is embodied as a request determining server, e.g. a so-called Floor Control Server (FCS) , which preferably forms part of the system infrastructure of the or one of the (e.g. 5G or LTE) communications systems.
  • the request determining control circuitry e.g. server
  • the group communications control circuitry e.g. server
  • the request determining control circuitry is embodied as a request determining server, e.g. a Floor Control Server, which may be (an internal) part of one or more of the communications stations of the system.
  • a request determining server e.g. a Floor Control Server
  • DMO Direction Mode of operation
  • 3GPP ProSE 3GPP ProSE
  • the system of the present invention comprises a plurality of communications stations.
  • Each of the communications stations may be any suitable such station or communications terminal, such as a mobile station (e.g. radio unit) or a suitable fixed terminal, such as a dispatcher terminal.
  • a mobile station e.g. radio unit
  • a suitable fixed terminal such as a dispatcher terminal.
  • each of the two (or more) communications systems (or subsystems) should (and preferably does) comprise one or more of the plurality of communications stations.
  • the plurality of communications stations preferably comprise one or more communications stations of a first communications system and preferably one or more communications stations of a second communications system (and optionally one or more communications stations of each of one or more further communications systems) .
  • the communications stations of the (or each) communications system should be (and preferably are) operable to send transmissions to and receive transmissions from the system infrastructure of the communications system in question.
  • the communications stations of the first communications system should be (and preferably are) operable to send transmissions to and receive transmissions from the system infrastructure of the first communications system
  • the communications stations of the second communications system e.g.
  • the communications stations of the second communications system should be (and preferably are) operable to send transmissions to and receive transmissions from the system infrastructure of the second communications system (and optionally communications stations of each of one or more further communications system should be (and preferably are) operable to send transmissions to and receive transmissions from system infrastructure of the respective further communications system) .
  • Each communications station may be operable to send transmissions to and receive transmissions from the appropriate system infrastructure in any suitable manner such as wirelessly, e.g. via an appropriate air interface, or via a fixed wire or similar (e.g. in the case of a fixed terminal) .
  • one or more of the communications stations may be operable to send transmissions to and receive transmissions from the appropriate system infrastructure via: the one or more portable cells, the one or more relay nodes, and/or the one or more repeater nodes. Other arrangements would be possible.
  • the system e.g. preferably (where present) the interconnection function or interworking function (IWF)
  • IWF interconnection function or interworking function
  • the system is configured such that one or more or each communications station of the communications system is able to send transmissions to and receive transmissions from any one or more or each of the one or more other communications stations (e.g. via the system infrastructure or otherwise) .
  • the system infrastructure preferably performs appropriate translation (or “transcoding” ) between the different signalling protocols and formats (codecs) used by the different communications systems.
  • the interworking function (IWF) , gateway, or the SwMI may be configured to perform the appropriate translation.
  • a communications station of the system is operable to transmit a request for permission to transmit to one or more communications stations of a set of plural communications stations of the system.
  • the set of plural communications stations preferably comprises plural communications stations that are associated together, e.g. that are members of the same (e.g. call) group.
  • the multiple communications stations will typically comprise a sub-set of all the communications stations of the system (although this need not be the case) .
  • the communications stations of the set may be selected as desired, e.g. by a user, group manager, or otherwise, to include any or all of the communications stations of the system as described herein.
  • Each of the multiple communications stations may, for example, be subscribed to the set (e.g. group) .
  • the set of plural communications stations includes one or more communications stations of each of two or more communications systems, e.g. of the two or more interconnected or interworking communications systems, i.e. the communications stations of the set are preferably distributed across two (or more) , preferably interconnected or interworking, communications systems.
  • the system is preferably configured such that transmissions intended for the set, e.g. sent by any one of the communications stations of the set, are shared between (all of) the communications stations of the set.
  • the system is preferably configured such that each of the communications stations in the set is operable to transmit to (to send transmission (s) to) (all of) the other communications stations in the set, and preferably such that each of the communications stations in the set is operable to receive transmissions that are intended for the set, e.g. that are sent from any one of the other communications stations in the set. That is, each communications station of the set is preferably operable to participate in a group call together with the other members of the group.
  • the set of plural communications stations may be configured as a single (e.g. call) group, e.g. across one or plural of the communications systems, or may be configured as a set of plural linked (e.g. call) groups, e.g. where each of the linked groups comprises communications stations of a single communications system, and where transmissions are shared between the set of plural linked (e.g. call) groups.
  • Transmissions intended for the set may be (and in one preferred embodiment are) transmitted using one or more particular, preferably selected, preferably designated, channels.
  • one or more or each of the communications stations of the set is preferably operable to receive transmissions sent using the one or more particular channels, e.g. in a “passive” manner, e.g. by “listening in” to the one or more particular channels.
  • Other arrangements would, however, be possible.
  • each of the one or more particular channels may comprise any suitable logical and/or physical channel.
  • the one or more particular channels may comprise plural different logical and/or physical channels, e.g. in respect of each of the communications systems.
  • each communications station of the set is operable, when it wishes to transmit to (to send a transmission or transmissions to) the other communications stations of the set, to (generate and) transmit a request for permission to do so.
  • the communications station preferably generates and transmits a request for permission to transmit to the one or more other communications stations of the set (e.g. group) .
  • the communications station may (generate and) transmit the request, e.g. in response to a user making an appropriate input, such as activating a “push-to-talk” button or other input device of the communications station.
  • an appropriate input such as activating a “push-to-talk” button or other input device of the communications station.
  • Other input arrangements such as the use of voice control, or automatic mechanisms based, e.g., on sensor inputs, etc., would be possible.
  • the transmission request is preferably transmitted to the request determining control circuitry (e.g. server) , e.g. via the system infrastructure or otherwise.
  • the request determining control circuitry e.g. server
  • the request may comprise any suitable request for permission to transmit to communications stations of the set, and may have any suitable form.
  • the transmission request is preferably configured as appropriate for the communications station and/or communications system in question.
  • the transmission request may comprise, for example, aso-called “floor request” .
  • the request may comprise a communication (message) (or part of a communication (message) ) whose main (or sole) purpose is to request permission for the communications station to send transmissions to the set of plural communications stations, i.e. an explicit request.
  • a communication messages
  • the request may comprise a communication (message) (or part of a communication (message) ) whose main (or sole) purpose is to request permission for the communications station to send transmissions to the set of plural communications stations, i.e. an explicit request.
  • Examples of such an explicit transmission (floor) request that may be used according to various embodiments are the TETRA “U-TX DEMAND” message, the TETRA “DM-GTX REQUEST” message, and the TETRA “ISI_TX-DEMAND” message. Other arrangements would, however, be possible.
  • the request may take the form of a communication (message) that has one or more other purposes, e.g. whose (main) purpose is not (is other than) to request permission for the communications station to send transmissions to the set, i.e. the request may comprise an implicit request.
  • a communication could be, for example, a communication (message) (or part of a communication (message) ) whose (main) purpose is to initiate a (group) call, or otherwise.
  • the communications station may instead begin performing the appropriate operations for initiating a (group) call (i.e. without producing a “standalone” transmission request) , e.g. by (generating and) transmitting one or more appropriate call initiation messages (e.g. one or more Session Initiation Protocol (SIP) messages) , and this message or messages may be interpreted and treated by the communications system as a transmission (floor) request.
  • group i.e. without producing a “standalone” transmission request
  • SIP Session Initiation Protocol
  • an implicit transmission (floor) request that may be used according to various embodiments is the SIP INVITE message, e.g. which may have the “mc_implicit_request” media level attribute that indicates an implicit transmission (floor) request.
  • SIP INVITE message e.g. which may have the “mc_implicit_request” media level attribute that indicates an implicit transmission (floor) request.
  • mc_implicit_request media level attribute that indicates an implicit transmission (floor) request.
  • information that indicates the time at which the transmission request was made is associated with the request.
  • the time-indicating information should be (and preferably is) indicative of (representative of) the time at which the request was made, i.e. the time at which the request (message) was produced and/or transmitted by the communications station and/or the time at which the input was made (e.g. the time at which the push-to-talk button or other input device was activated) .
  • the time-indicating information may comprise any suitable such information and may take any suitable form.
  • the time-indicating information comprises an absolute (global) time value, e.g. a so-called “time stamp” .
  • the time-indicating information may comprise the absolute time value at which the request (message) was produced and/or transmitted by the communications station and/or the absolute time at which the transmission request input was made.
  • the time-indicating information may additionally or alternatively comprise a relative time value, e.g. a time offset (time difference) .
  • the time-indicating information may be associated with the transmission request in any suitable manner. In a preferred embodiment, it is included in the transmission request and/or in a communication (message) that includes the transmission request. This ensures that the time-indicating information is linked with the request, and can accordingly be used in a straightforward manner when the determination of whether (or not) and/or when to grant the request is made, i.e. when the request is received, e.g. by the request determining control circuitry.
  • the time-indicating information could, for example, be included in the main body of the communication (message) that includes the transmission request. This is particularly beneficial in terms of security, since for example, the body of the communication (message) may be encrypted, e.g. for transmission to the request determining control circuitry (e.g. server) (and in a preferred embodiment this is done) .
  • the request determining control circuitry e.g. server
  • the time-indicating information could be included in another part of the communication (message) , such as for example, the header (e.g. SIP header) , or other transport or control layers.
  • the time-indicating information may be included in the SIP “Timestamp” header field of an (implicit) transmission (floor) request, or in the SIP “Delay” header field of an (implicit) transmission (floor) request (other arrangements would be possible) .
  • These fields have sufficient accuracy to be able to handle millisecond level time-indicating information.
  • These embodiments have the advantage of being realised with less computational effort compared to modifying the main body of a communication (message) .
  • time-indicating information as a media level attribute of a SIP session.
  • the time-indicating information may be associated with (e.g. included in) the transmission request by any suitable part of the communications system.
  • the time-indicating information is associated with the request by the communications station. Accordingly, the time-indicating information is preferably generated by the communications station, and preferably then associated with the request, e.g. by the communications station including the time-indicating information in the transmission request (message) .
  • the Applicants have recognised that it may not always be possible or desirable for the communications station itself to associate the time-indicating information with the transmission request. For example, it may not be possible or desirable to modify the operation of an existing communications station, e.g. in terms of cost, etc., in some existing systems. Equally, the structure of communications (messages) produced by communications stations of some communications systems may not allow for the inclusion of the time-indicating information.
  • the time-indicating information is (generated and) associated with the transmission request by some other (suitable) part of the communications system, preferably some (suitable) part of the system infrastructure.
  • the system infrastructure of the communications system may (and preferably does) generate the time-indicating information, and may (and preferably does) associate the time-indicating information with the transmission request.
  • a method of operating a communications system comprising:
  • a communications station of the communications system transmitting a request for permission to transmit to one or more communications stations of a set of plural communications stations of the communications system;
  • the communications system using the information when determining whether and/or when the request for permission for the communications station to transmit should be granted.
  • a communications system comprising:
  • system infrastructure is configured, when a communications station transmits a request for permission to transmit to one or more communications stations of a set of plural communications stations, to associate with the request information indicating the time at which the request was made;
  • the communications system is configured to use the information when determining whether and/or when the request for permission for the communications station to transmit should be granted.
  • the communications system may be a “standalone” communications system, e.g. and preferably comprising any one of the communications systems described above, or may be one of two or more interconnected or interworking communications systems, e.g. and preferably as described above.
  • the communications system comprises a (digital or analogue) Land Mobile Radio (LMR) (or Private Mobile Radio (PMR) ) communications system, e.g. as described above.
  • LMR Land Mobile Radio
  • PMR Private Mobile Radio
  • any suitable part of the system infrastructure may be operable to (generate and) associate the time-indicating information with the transmission request.
  • any suitable functional part, e.g. “node” of the system through which the transmission request passes (i.e. is routed) between the communications station and the request determining control circuitry (e.g. server) may be operable to associate the time-indicating information with the transmission request.
  • transmission requests from the (and preferably each) communications station are transmitted to the request determining control circuitry (e.g. server) via one or more intermediate nodes of the (system infrastructure of the) system, and one or more of the one or more intermediate nodes is preferably operable to (generate and) associate time-indicating information with the transmission request.
  • the request determining control circuitry e.g. server
  • one or more of the one or more intermediate nodes is preferably operable to (generate and) associate time-indicating information with the transmission request.
  • intermediate node There may be only a single part, e.g. intermediate node, of the system that is operable to (generate and) associate time-indicating information with transmission requests, or there may be plural different parts, e.g. intermediate nodes, of the system that are each operable to (generate and) associate time-indicating information with transmission requests.
  • an Application Server of the communications system in question e.g. for example a SwMI of a TETRA system
  • the interconnection or interworking function IWF may be operable to (generate and) associate time-indicating information with transmission requests.
  • Other arrangements would, however, be possible.
  • the system of the present invention may be configured such that time-indicating information is associated with (e.g. included in) transmission requests using only one of the above described techniques, e.g. by communications stations associating time-indicating information with transmission requests, or by system infrastructure associating time-indicating information with transmission requests.
  • the system is configured such that time-indicating information can be (and preferably is) associated with (e.g. included in) transmission requests using plural different ones of the above described techniques, e.g. by (some but not all) communications stations associating time-indicating information with their requests, and by system infrastructure associating time-indicating information with (some but not all) requests.
  • a particular communications station e.g. of a particular one of the two (or more) communications system of the present invention
  • it preferably does so.
  • the system infrastructure preferably associates time-indicating information with these transmissions requests.
  • the system infrastructure that is operable to associate time-indicating information with transmission requests may be (and preferably is) operable to selectively associate time-indicating information with transmission requests.
  • the system is preferably operable to determine whether (or not) a request has time-indicating information associated with it. Where it is determined that a transmission request does not have (has other than) associated time-indicating information, then the (particular part, e.g. node, of the) system infrastructure is preferably operable to associate time-indicating information with the transmission request. Correspondingly, where it is determined that a transmission request does have associated time-indicating information, then the (particular part, e.g. node, of the) system infrastructure preferably does not associate (other than associates) time-indicating information with the transmission request.
  • the determination of whether (or not) a request has time-indicating information associated with it, and correspondingly the determination of whether (or not) a (particular part, e.g. node, of the) system infrastructure should associate time-indicating information with a transmission request may be made by the particular part, e.g. node, of the system infrastructure that is operable to associate time-indicating information with transmission requests or by some other part of the system, e.g. some other part, e.g. node, of the system infrastructure.
  • the (particular part, e.g. node, of the) system infrastructure that is operable to associate time-indicating information with transmission requests may be instructed as to whether it should associate time-indicating information with transmission requests, e.g. by some (other) part of the system infrastructure controlling whether the particular part, e.g. node, should associate time-indicating information with transmission requests.
  • the (particular part, e.g. node, of the) system infrastructure may be operable to decode (e.g. decrypt) (and preferably then recode (e.g. re-encrypt) ) the transmission request as appropriate.
  • decode e.g. decrypt
  • recode e.g. re-encrypt
  • the transmission request is encrypted, e.g. using one or more encryption keys.
  • the communications station and e.g. the group communications control circuitry (e.g. server) and/or the request determining control circuitry (e.g. server) have access to (i.e. are provided with) the one or more encryption key (s) .
  • the (particular part, e.g. node, of the) system infrastructure that is operable to associate time-indicating information with transmission requests (and/or the other controlling part, e.g. node, of the system infrastructure) preferably also has access to (i.e. is provided with) the one or more encryption key (s) .
  • the (particular part, e.g. node, of the) system infrastructure is preferably operable to decode a received transmission request, e.g. using the one or more encryption keys, to optionally determine whether (or not) the request has time-indicating information associated with it, to associate time-indicating information with the (decrypted) request (e.g. selectively, where necessary) or to instruct another part, e.g. node, of the system infrastructure to associate time-indicating information with the (decrypted) request (e.g. selectively, where necessary) , and preferably to then encrypt the (optionally modified) request (e.g. using the one or more encryption keys) , e.g. for onward transmission, e.g. to the group communications control circuitry and/or request determining circuitry or otherwise.
  • the system infrastructure associates time-indicating information with a request (and otherwise)
  • the system infrastructure will not typically have knowledge of the precise time at which the request (message) was made by the communications station.
  • the (particular part, e.g. node, of the) system infrastructure that is operable to associate time-indicating information with transmission requests may (and preferably does) have knowledge of the (absolute) time at which the request (message) was received by the (particular part, e.g. node, of the) system infrastructure.
  • the (absolute) time (e.g. a “time stamp” ) at which the request (message) is received by the (particular part, e.g. node, of the) system infrastructure that is operable to associate time-indicating information with transmission requests is used as or to derive the time-indicating information.
  • the (absolute) time at which the request (message) is received by the (particular part, e.g. node, of the) system infrastructure is used together with and/or is modified by an appropriate time offset that is configured to (try to) take into account the time taken for the request to arrive at the (particular part, e.g. node, of the) system infrastructure, e.g. from the communications station or from some other part, e.g. node, of the system infrastructure.
  • time offset that is additionally or alternatively configured to (try to) take into account the time taken for the request to be transmitted from the particular part, e.g. node, of the system infrastructure that is operable to associate time-indicating information with the transmission request to some other part, e.g. node, of the system infrastructure (such as, for example, the group communications control circuitry or the request determining control circuitry) (and in one preferred embodiment, this is done) .
  • the time-indicating information comprises one or more relative time values, e.g. time offset (s) (time difference (s) ) , which may be provided in addition to or alternatively to, or which may be used to modify, an absolute time value.
  • time offset e.g. time offset (s) (time difference (s) )
  • the time-indicating information can (and preferably does) comprise one of: the (absolute) time at which the request (message) is received by the (particular part , e.g. node, of the) system infrastructure, a relative time value, both the (absolute) time at which the request (message) is received by the (particular part, e.g. node, of the) system infrastructure and a relative time value, or the (absolute) time at which the request (message) is received by the (particular part, e.g. node, of the) system infrastructure modified by a relative time value.
  • time-indicating information comprises, for example, both the (absolute) time at which the request (message) was made and a relative time value, or the (absolute) time at which the request (message) was made modified by a relative time value.
  • the relative time value may be used to modify the absolute time value by appropriately adding or subtracting the relative time value to or from the absolute time value.
  • the relative time value (s) may be associated with the request by the same part of the system that associates the absolute time value with the request (e.g. the Application Server or the interconnection or interworking function (IWF) ) .
  • the relative time value (s) may be associated with the request by a different part of the system (e.g. the group communications control circuitry or the request determining control circuitry) than the part that associates the absolute time value with the request (e.g. the Application Server or the interconnection or interworking function (IWF) ) .
  • a seventh aspect of the present invention there is provided a method of operating a communications system, the method comprising:
  • a communications station of the communications system transmitting a request for permission to transmit to one or more communications stations of a set of plural communications stations of the communications system;
  • the communications system using the information when determining whether and/or when the request for permission for the communications station to transmit should be granted.
  • a communications system comprising:
  • system is configured, when a communications station transmits a request for permission to transmit to one or more communications stations of a set of plural communications stations, to associate with the request information indicative of a time for the request to be transmitted from one part of the communications system to another part of the communications system;
  • the communications system is configured to use the information when determining whether and/or when the request for permission for the communications station to transmit should be granted.
  • the communications system may be a “standalone” communications system, e.g. and preferably comprising any one of the communications systems described above, or may be one of two or more interconnected or interworking communications systems, e.g. and preferably as described above.
  • the communications station may itself associate the information with the request, or system infrastructure of the communications system may associate the information with the request, e.g. and preferably as described above.
  • the relative time value may comprise any suitable such relative time value, e.g. that may be configured to (try to) take into account the time taken for the request to arrive at the (particular part of the) system infrastructure from the communications station, or the time taken for the request to be transmitted from one part of the communications system to another part of the communications system (or otherwise) , and may be determined in any suitable manner.
  • the relative time value comprises one or more constant, preferably fixed, relative time values.
  • a constant relative time value may be configured, e.g. to take into account of (estimated or average) delay time for transmissions from the communications station to the system infrastructure (which may include factors such as random-access channel (RACH) opportunity delay, frame structure, etc. ) , and/or (estimated or average) delay time for transmissions through the system infrastructure, e.g. to the request determining control circuitry.
  • RACH random-access channel
  • the relative time value may comprise one or more variable, preferably dynamic, relative time values.
  • the time-indicating information may comprise a variable relative time value, where the relative time value may vary e.g. depending on one or more particular conditions of the communications system.
  • the relative time value may vary depending on, for example, the route taken by the request between the communications station and the system infrastructure, and/or the route taken by the request through the system infrastructure.
  • the relative time value may vary depending on whether (or not) the request has been transmitted via a portable cell, via one or more relay and/or repeater nodes, and/or on the particular backhaul transport traversed by the request. Other arrangements would be possible.
  • the value of the variable relative time value may be determined as desired.
  • the value of the variable relative time value is determined using knowledge of the transport routing of the request. This may be determined, for example, using: one or more associated connecting network functions, one or more associated IP addresses, and/or one or more associated ports.
  • the value of the variable relative time value is determined using one or more time delay measurements.
  • Various exemplary embodiments include the use of: one or more PING messages, one or more keep-alive, heartbeat or Dead Peer Detection (DPD) messages, one or more SIP OPTIONS messages, and/or one or more Real-Time Transport Protocol (RTCP) messages.
  • PING messages one or more keep-alive, heartbeat or Dead Peer Detection (DPD) messages
  • DPD Dead Peer Detection
  • SIP OPTIONS SIP OPTIONS
  • RTCP Real-Time Transport Protocol
  • the part or parts of the communications system that is operable to associate the time-indicating information with the request should (and preferably do) comprise and/or have access to one or more (accurate) time sources.
  • time sources include time sources that use, for example, Global Navigation Satellite System (GNSS) , Global Positioning System (GPS) , Network Time Protocol (NTP) , System Information Broadcast, and Precision Time Protocol techniques. Other arrangements would be possible.
  • additional information may also be associated with the transmission request.
  • the additional information may comprise any suitable information, e.g. in addition to the time-indicating information.
  • the additional information may be associated with the transmission request in any suitable manner, e.g. by including it in the transmission request in a corresponding manner to that described above.
  • the additional information is preferably associated with the transmission request by the same part of the system that associates the time-indicating information with the transmission request (and preferably at the same time) , although this is not necessary.
  • the additional information comprises information indicating the source of the time-indicating information (e.g. indicating the particular time source used to obtain the time-indicating information) . Additionally or alternatively, the additional information may comprise information indicating the quality of the time-indicating information. Additionally or alternatively, the additional information may comprise information indicating whether the time-indicating information was obtained via the system infrastructure or autonomously. Such additional information may be used, e.g., to determine the quality and/or reliability of the time-indicating information, and/or to take into account any timing differences between the time source used to obtain the time-indicating information and another time source (e.g. used by the request determining control circuitry or otherwise) , e.g. when determining whether and/or when the request for permission for the communications station to transmit should be granted.
  • additional information may be used, e.g., to determine the quality and/or reliability of the time-indicating information, and/or to take into account any timing differences between the time source used to obtain the time-indicating information and another time source (e.g. used by the request determining
  • the additional information may comprise information indicating where in the system the time-indicating information was associated with the transmission request (e.g. by the communications station or by a particular part, e.g. node, of the system infrastructure) . Additionally or alternatively, the additional information may comprise information indicating how the time-indicating information is to be interpreted (e.g. indicating whether a relative time value applies to some or all the time taken for the request to arrive at the request determining control circuitry from the communications station) . Such additional information may be used, e.g., to ensure that the time-indicating information is used appropriately, e.g. when determining whether and/or when the request for permission for the communications station to transmit should be granted
  • the additional information may comprise information indicating how the time-indicating information was obtained (e.g. whether by estimation or use of one or more measurements, etc. ) .
  • the system uses the time-indicating information when determining whether and/or when the request for permission for the communications station to transmit should be granted.
  • the system (and preferably the request determination control circuitry) is preferably configured to receive the transmission request and preferably to then determine whether and/or when the request for permission for the communications station to transmit should be granted.
  • the system may be configured to determine whether (or not) the request for permission for the communications station to transmit should be granted, and/or the system may be configured to determine when the request for permission for the communications station to transmit should be granted.
  • the system may be configured to make the determination in any suitable manner.
  • the determination is made on a first-come-first-served basis.
  • the determination may take into account one or more other factors, such as for example, a priority assigned to the particular communications station, and/or a priority assigned to the particular type of transmission that the communications station wishes to make. Other arrangements would be possible.
  • the time-indicating information is preferably used by the communications system to calibrate its decision making process.
  • the time-indicating information is preferably used to determine which of the communications stations should be granted permission to transmit to the set (and correspondingly which of the communications stations should be denied permission, or granted permission to transmit to the set at a later time, or otherwise) .
  • a transmission request whose time-indicating information indicates that it was made before another request may be (and preferably is) granted ahead of the other request.
  • the transmission request whose time-indicating information indicates that it was made before the other request is preferably granted ahead of the other request.
  • the request may be denied or its grant may be delayed, e.g. the request may be queued.
  • the request may be granted, and the other communications station’s permission to transmit to the group may be rescinded.
  • the communications station in question is preferably informed, e.g. by sending an appropriate grant-indicating transmission (message) to the communications station.
  • the communications station is preferably operable to then begin to transmit to the one or more communications stations of the set.
  • the transmissions sent to the set may comprise any suitable transmissions, such as voice, video or data, etc.
  • the communications station in question may be informed, e.g. by sending an appropriate transmission (message) to the communications station.
  • the communications station preferably then does not transmit to the set.
  • the communications station is preferably informed, and then may subsequently be informed when the request is granted, e.g. by reaching the front of the queue.
  • the communications system preferably then begins transmitting to the set.
  • the system of the present invention may be configured with a maximum allowable time delay (time-indicating information) in respect of transmission requests.
  • a maximum allowable time delay time-indicating information
  • any transmission request whose time-indicating information indicates that the timing delay exceeds the maximum value may, for example, be processed differently to other requests, e.g. may be prioritised or otherwise, when determining whether and/or when the request for permission for the communications station to transmit should be granted.
  • the maximum allowable time delay may or may not include an allowance for the time taken for a grant-indicating transmission to be sent to the communications station in question.
  • the system of the present invention may be operable to queue transmission requests.
  • a communications station can, in principal, send a transmission request at any time, including when another communications station is transmitting to the set of plural communications stations.
  • communications stations may be configured to send their transmission requests only when notified by the system that they are permitted to do so, e.g. by the system sending communications (messages) to the communications stations (explicitly or implicitly) indicating that permission has been granted to transmit transmission requests.
  • the Applicants have furthermore recognised that the time delay for a communications station to receive such a permission notification can be significantly different from one communications station to the next, and that this can again mean that some communications stations of the system can have an advantage in being able to be granted permission to transmit to the set of plural communications stations.
  • the communications system may be configured to take such time delays into account when determining whether and/or when a request for permission for a communications station to transmit should be granted.
  • the communications system may be configured to send notifications to different communications stations of the system at different times, preferably depending on the time delay between the part, e.g., node, of the communications system that transmits the permission notification (s) (e.g. and preferably the group communications control circuitry) and the communications station or stations in question, e.g. to (try to) ensure that all of the communications stations receive the permission notification at substantially the same time.
  • the permission notification e.g. and preferably the group communications control circuitry
  • a ninth aspect of the present invention there is provided a method of operating a communications system, the method comprising:
  • transmitting the notification to the set of plural communications stations comprises:
  • a communications system comprising:
  • system is configured to transmit to a set of plural communications stations a notification indicating that the communications stations can request permission to transmit to the set of plural communications stations;
  • system configured transmit the notification to the set of plural communications stations by:
  • transmissions to the one or more first communications stations preferably experience a first transmission time delay
  • corresponding transmissions to the one or more second communications stations preferably experience a second different transmission time delay
  • the first and second times at which the notification is respectively sent to the one or more first communications stations and the one or more second communications stations preferably depend on these different time delays, e.g. and preferably to (try to) ensure that the notification is received by the first and second communications station substantially at the same or similar times.
  • Communications stations that experience a greater transmission time delay preferably have their notifications sent at an earlier time compared to communications stations that experience a lesser transmission time delay.
  • the system may be configured to transmit the notification to one or more third or further communications stations of the set at a third or further different time, e.g. where transmissions to the one or more third or further communications stations (e.g. from the group communications control circuitry of the system or otherwise) preferably experience one or more third or further different transmission time delays.
  • Each of the time delays is preferably determined using the time taken for a transmission request to arrive from a respective communications station, or some other previously determined or configured estimates of the time delays, e.g. and preferably as described above.
  • a single notification may be sent in respect of one or plural communications stations.
  • the location of the communications stations may be taken into account, e.g. in order to combine the notifications for communications stations that are within a similar location in the system (e.g. within the same LTE Multimedia Broadcast and Multicast Services (MBMS) Service Area) into a single notification.
  • MBMS Multimedia Broadcast and Multicast Services
  • the notification may be sent by the part, e.g. node, of the communications system that generates the notification (e.g. and preferably the group communications control circuitry) at the first and second different times.
  • the notification may be sent by the part, e.g. node, of the communications system that generates the notification at the same time, but may then be forwarded on to the respective communications stations by one or more different parts, e.g., one or more nodes, of the system at the first and second different times.
  • the part, e.g. node, of the communications system that generates the notification e.g. and preferably the group communications control circuitry
  • the one or more intermediate nodes may use this information to determine when to forward the notification (s) to the respective communications stations, and may then forward the notification (s) to the respective communications stations at the appropriate times. Accordingly, the different permission notification delay times may be addressed using a timestamp provided to one or more of the intermediate nodes.
  • the methods in accordance with the present invention may be implemented at least partially using software e.g. computer programs. It will thus be seen that when viewed from further aspects the present invention provides computer software specifically adapted to carry out the methods hereinabove described when installed on data processing means, and a computer program element comprising computer software code portions for performing the methods hereinabove described when the program element is run on data processing means.
  • the invention also extends to a computer software carrier comprising such software which when used to operate a communications system and a communications station comprising data processing means causes in conjunction with said data processing means said system or station to carry out the steps of the method of the present invention.
  • a computer software carrier could be a physical storage medium such as a ROM chip, CD ROM or disk, or could be a signal such as an electronic signal over wires, an optical signal or a radio signal such as to a satellite or the like.
  • FIG. 1 shows schematically a communications system in accordance with an embodiment of the present invention
  • FIG. 2 shows schematically a communications system in accordance with an embodiment of the present invention.
  • Figure 3 shows schematically a method in accordance with an embodiment of the present invention.
  • Preferred embodiments of the present invention are directed to techniques for floor control alignment within or across interconnected or interworking communication systems.
  • Mission Critical (MC) Systems are evolving and it is envisioned that there may be many more Application Servers and an increased range of services, including but not limited to voice, video and data, offered to groups of users and devices, and with a range of quality of service, using Group Call techniques.
  • permission to transmit media may be allocated by a Floor Control Server (FCS) associated with the Application Server.
  • FCS Floor Control Server
  • MC Voice systems such as TETRA
  • a request to transmit media is made whilst another person or device has the floor, it may either be queued or rejected; if the request is made after a voice segment has terminated, permission to transmit media may be allocated based on one or more inputs, possibly including but not limited to: position in queue, priority of the user, priority of the service request, or may just be on a first-come first-served basis.
  • interconnection and interworking are used herein interchangeably, unless the context requires otherwise.
  • the floor control for a service requiring floor control may rest with a single application server and related Floor Control Server from within the interworked systems. Accordingly, the combined systems are much more heterogeneous in nature with differing characteristics. Consequently the nature of time delays is also typically much more heterogeneous and may be influenced by the type and configuration of the systems involved, including at radio level, and transport level (e.g. due to the use of Very Small Aperture Terminal (VSAT) satellite backhaul, etc. ) .
  • VSAT Very Small Aperture Terminal
  • the time delays may be significant.
  • the length of a TETRA time slot (14 ms) is already approximately 1/3 of the expected one-way delay (approximately 40 ms) from an LTE terminal to the application layer.
  • the introduction of an interworking function between one system and the system controlling the Floor will introduce additional delays across this interworking function.
  • gateway cells can be deployed for purposes including, but not limited to, coverage and range extension, capacity, and additional services, which may make use of a backhaul that includes the existing macro-network.
  • the architecture of such arrangements inherently introduces additional delays because the user signal has, in addition to normal transport through the mobile network, to travel through both the gateway cell and the mobile terminal transmitting back to the macro network. Consequently aspects of LTE systems themselves are also becoming more heterogeneous.
  • Preferred embodiments are related to methods of including timestamps with floor requests and methods of using the timestamps to equalise media transmission opportunities between disparate requesting devices.
  • the 3rd Generation Partnership Project (3GPP) has developed a range of standards, including 3G and a Long Term Evolution (LTE) Radio Access Network (RAN) standard which is combined with an Evolved Packet Core (EPC) to create a high speed wireless network that can connect a device to a Packet Data Network (PDN) in order to carry a range of user traffic, including but not limited to, voice, video and data files.
  • PDN Packet Data Network
  • Examples of such a PDN include a Session Initiation Protocol (SIP) core network, or specific enhancements to a SIP Core, known as the IMS (IP Multimedia Subsystem) .
  • SIP Session Initiation Protocol
  • IMS IP Multimedia Subsystem
  • MC Mission Critical
  • MCPTT Mission Critical Push to Talk
  • Such communications typically operate by groups of people subscribing to one or more designated groups, and listening in to transmissions on a shared logical or physical channel for transmissions targeted at one of the groups to which they are subscribed.
  • An individual user can typically request permission to speak by pushing a button on their device to request the floor (or otherwise) .
  • This causes the MC client to request transmission of a signal to the controlling Application Server requesting permission to speak, also known as a Floor Request.
  • a successful response from the Application Server to the MC client is known as a Floor Grant.
  • this Application Server is known as the MCPTT server, with the particular logical function processing the floor requests known as the Floor Control Server (FCS) .
  • FCS Floor Control Server
  • the FCS may take into account a number of factors, including but not limited to the most recent message received, relative priority of any requesters making request for, or queuing for, the floor, and the ability to over-ride the current speaker. If the channel is not being used and there is no queue then it is likely that the first received request will be granted the floor.
  • floor requests that are not immediately successful may be queued until the floor again becomes available and the request is re-assessed, and the originator of the floor request may be kept informed, or be able to request information about its position in the queue.
  • 3GPP and existing technologies such as TETRA have also developed off-network solutions, sometimes designated Direct Mode, where one or more terminals may not be in communication with the core network, and it is necessary for one or more terminals to communicate off-network in a point to point or point-to-multipoint fashion.
  • the Floor Control server function for a particular group call may sit within a terminal (typically that of the current talker) rather than above one or more Packet Data Networks.
  • the technology described herein is applicable to such scenarios but for simplicity the preferred embodiments are described in terms of an on-network realisation.
  • Figure 1 illustrates a general system design in order to describe the configuration and operation of a Mission Critical system interworking with another Mission Critical system based on the same or a different technology according to an embodiment.
  • a Mission Critical User Equipment (UE) 101 incorporating an MC client 102 transmits and receives data over one or more radio bearers from a base station 103 (which may be known as an eNodeB in LTE systems) .
  • User data and related control signalling is then routed back to an Evolved Packet Core 104.
  • Mission Critical related traffic transmitted by the MC client, or intended for MC clients is routed through a SIP Core PDN 105 to the Mission Critical System 106.
  • Application control messages (such as floor requests) included in that traffic are handled by a function within the system known as the Floor Control Server (FCS) 107.
  • FCS Floor Control Server
  • the FCS takes received messages and applies the system rules for determining whether and when a floor grant request is accepted and acted upon.
  • the security architecture for the 3GPP system has been designed to take account that the SIP Core 105 may be in a different domain of trust from both the cellular network and Evolved Packet Core 104, and the Mission Critical system 106. This is principally achieved by encrypting the contents of message bodies between the MC client 102 and the MC Server system 106.
  • a mechanism for LTE to improve coverage or add capacity in a particular area is to deploy portable cells at or near where the coverage is required.
  • one or more UEs 109 incorporating an MC client transmits and receives data from a gateway cell, which may be realised as a local base station 110, which in turn is operationally connected to a UE 111 that transmits and receives from a further base station 103 that is connected to the EPC 104, which in turn routes and connects that UE data to an Offload Gateway 112.
  • the data traffic from the mobile device (s) 109 is taken from the local cell 110 and encapsulated as user data of the UE 111 as far as the Offload Gateway 112.
  • the Offload Gateway 112 receives that user data and extracts the data pertaining to individual UEs 109 and sends this towards a packet gateway within the EPC 104 that is able to provide access to a SIP core 105 and thence the Mission Critical System 106 and Floor Control Server 107.
  • the traffic from the UE 109 will have passed through an additional air interface, local base station 110, UE 111 and Offload Gateway 112 before reaching the Floor Control Server 107.
  • Mission Critical systems There are further deployment architecture options amongst Mission Critical systems, including use of relay and repeater nodes, e.g. including those where one mobile device acts as a relay towards the core network for another.
  • Examples of such architectures include the Proximity Services (ProSe) architecture and protocols defined by 3GPP, and the TETRA Direct Mode of operation (DMO) with a gateway mobile device.
  • ProSe Proximity Services
  • DMO TETRA Direct Mode of operation
  • each intermediate node has the potential to increase the delay in transmission of a Floor Request.
  • one Mission Critical system may interwork or interconnect with another Mission Critical system 113.
  • the two systems may be of the same type, subsystems of a larger system, or may be different types, and may be logically connected via an Interworking Function (IWF) 114.
  • the IWF 114 may need to convert between signalling and media formats of the respective systems to ensure successful interoperation.
  • a policy should be established, e.g. by the respective system operators, as to which system and Floor Control Server handles the Floor Grant requests, denoted the primary system and FCS respectively.
  • this is the Floor Control server 107.
  • a Floor Request made by a mobile device 115 on the other Mission Critical System 113 will have an additional transport delay in comparison with other devices, caused by the further transport to the IWF 114 and onwards to the FCS 107.
  • Table 1 is taken from “3GPP Technical Report TR 36.868 “Study on group communication for E-UTRA” , and describes an estimate of the time to set up a group communication from when a UE in Idle Mode is requested to initiate a group call (for instance by a signal from an MC client) and when the user receives the Floor Grant and is able to start speaking.
  • the estimate assumes that receiving UEs already have bearers pre-established to receive group transmission, and so this aspect does not add to the total setup time.
  • 3GPP standards call for a target of 300 ms from a floor request to when the user is able to start speaking. It should be noted from Table 1 that whilst the MCPTT Server is estimated to take 55 ms to carry out its processing, the end-to-end setup time shows that there is further margin between the 250 ms total and the 300 ms target. It is possible that an MC deployment might wish to relax this target in order to provide greater flexibility for a particular system.
  • 3GPP has more recently defined new Quality Class Indicators (QCIs) for bearers designated especially for the purposes of carrying Push-to-Talk Communication signalling and media that may potentially reduce this latency still further.
  • QCIs Quality Class Indicators
  • 3GPP specifications have applied encryption techniques to protect certain Mission Critical protocol messages from being read by untrusted domains that the message may be carried through.
  • 3GPP TS 33.179 Section 7.3.5.3 describes how group keys for security may be distributed for multiple 3GPP MCPTT systems under the group regrouping procedure used to create a ‘super’ group consisting of members from two LTE systems.
  • the Mission Critical MCPTT system that is designated as the primary system for the combined group creates group keys and identities for the temporary group. These are distributed to users on the primary system and also to the Group Management Server (GMS) on the other partner LTE system (s) .
  • the partner GMS is treated as another user within the primary group.
  • the payload encrypts the new Group Management Key (GMK) to the identity of the partner GMS and is signed using the identity of the primary GMS.
  • GMK Group Management Key
  • the Group User Key Identifier (GUK-ID) is derived using the User Salt generated from the partner GMS’s Uniform Resource Identifier (URI) .
  • the partner GMS extracts the GMK and GMK-ID from the notification.
  • the partner GMS then notifies the affiliated users within the partner MCPTT system.
  • On-network Floor control signalling is ciphered on a hop-by-hop basis and may be protected using the SRTCP mechanism (IETF RFC 3711) , as described in 3GPP TS 33.179 Section 7.6 using a shared master key amongst the group, the keys being distributed using the group key distribution method described above. A similar approach is adopted in the case of a Private Call.
  • SRTCP mechanism IETF RFC 3711
  • an intermediate node in addition to the intended MCPTT Server, has received the relevant management key (s) , it is able to detect and decode Floor Request messages, and re-cypher such modified messages if desired.
  • timing corrections are introduced using calculations that depend on the use of an optional time stamp, and/or time offset, into Floor Requests. This can be done globally across an LTE system, and/or solely for those Floor Requests travelling across an interworking or interconnection function, or between two connected systems without an interworking or interconnection function, to allow the controlling Floor Control Server to calibrate its decision making.
  • such a time-stamp is created or introduced for interworked systems.
  • Such a time-stamp may be included in the main body of a message containing an implicit or explicit floor request, or in other parts including, but not limited to, the SIP header, or other transport or control layers.
  • the interworking or interconnection function may appear as a group member to the Group Management Server and as a Group Management Server and Floor Control Server to its related communications stations, UEs and MSs further away from the primary MCPTT system and is thereby included in the relevant key distribution and has the potential to read a Floor request message, create and associate a time stamp and if necessary re-encrypt the message.
  • Table 2 shows the U-TX DEMAND message contents that a TETRA terminal currently includes in its request to transmit in the case that it is attached to a TETRA SwMI without going through a gateway.
  • Table 4 Contents of ISI_TX-DEMAND message (source: ETSI EN 300 392-3 section 5.2.2.16)
  • Floor Request time-stamping is used for interworking systems. Also described herein are methods and apparatus for calculating and inserting such a time-stamp or similar offset, as well as the use of an IWF 114 as a proxy Group Management Server and Floor Control Server, with the ability not just to modify transport addresses, but also the contents of message bodies to add time-stamps.
  • Time-stamping according to the present invention can be realised in number of different ways, e.g. depending on the capabilities of the interconnecting systems and security requirements.
  • atime-stamp may be introduced into the originating Floor Request message (e.g. at a client on the UE) . This may be included in that message and carried through to the inter-system interface
  • a time-stamp may be added at the source infrastructure application server (for example the SwMI of a TETRA system) , or at the Interworking Function 114 between the two systems.
  • Such a time-stamp may optionally be set to include an offset against an actual time, e.g. to compensate for other delays, including for example, an optional representation of the estimated or average radio access delay of the source system (which may include elements such as RACH opportunity delay, Frame structure (which can total up to 63.75 ms in the case of TETRA) , etc. ) , or the latency between the source system and the system in charge of Floor Control.
  • an optional representation of the estimated or average radio access delay of the source system which may include elements such as RACH opportunity delay, Frame structure (which can total up to 63.75 ms in the case of TETRA) , etc.
  • the latency between the source system and the system in charge of Floor Control may optionally be set to include an offset against an actual time, e.g. to compensate for other delays, including for example, an optional representation of the estimated or average radio access delay of the source system (which may include elements such as RACH opportunity delay, Frame structure (which can total up to 63.75 m
  • a time-stamp or offset compensation may also be dynamically inserted, based on factors such as on-going indicators, including but not limited to the following:
  • the type of the backhaul transport (e.g. VSAT) . This may be identified, e.g., by a message’s transport routing (including but not limited to connecting IP address and/or port into a network function) .
  • the transport routing that a message has used i.e. not just the backhaul
  • This may be identified, e.g., by a message’s transport routing (including but not limited to connecting network function, IP address and/or port into a network function) .
  • c) Measurements of the delay along a connecting link e.g. based on a calculation or estimation of the round trip time from certain messages and their responses.
  • Examples in the transport layer include, but are not limited to: (i) explicit server PING messages using TCP/IP that are responded to; and (ii) keep-alive, heartbeat and Dead Peer Detection (DPD) messages from protocols such as IKE, IPSec and SCTP where the remote endpoint responds as soon as it has received certain incoming messages.
  • DPD Dead Peer Detection
  • Measurements of round trip delay for higher layer messages including application layer messages that require a response from the remote endpoint. Examples include, but are not limited to the SIP OPTIONS method if an endpoint is configured to act as STUN (Session Traversal Utilities for NAT) server.
  • STUN Session Traversal Utilities for NAT
  • Explicit application layer messages intended to assist round trip time estimation. Examples include, but are not limited to RTCP messages during session operation and specific response capabilities in the Mission Critical client function.
  • any time-stamp or offset compensation applied may also have one or more additional qualifiers associated with it, e.g. that indicate the source and quality of the time-stamp information. This may include, but is not limited to: GPS, NTP, or wireless network System Information Broadcast listened to by the mobile device, and/or whether the source was obtained via or with the assistance of the network serving the device or autonomously.
  • NTP is typically derived in a network from multiple time-servers, and if delivered securely is very difficult to spoof.
  • the time broadcast by an LTE radio access network in System Information Block Type 16 is not ciphered, and could potentially be interfered with by a malicious entity simultaneously broadcasting a stronger signal with different values.
  • this also has the advantage of enabling the receiving entity to calculate relative offsets if it is using a different accurate timing source itself.
  • any time-stamp or offset compensation applied may also have an additional qualifier applied that indicates the location (either in a network, or functional entity) where the offset was entered and/or whether such a time-stamp or offset compensation was intended to cover all previous legs of the transport.
  • This has the advantage of allowing a receiving entity such as a floor control server to optionally include any further timing offset needed, such as compensation for delays incurred before the time-stamping location, into its calculations.
  • a further additional offset may be applied to take account of the expected transport time of the message from the device to the TETRA SwMI. This may optionally be applied at the SwMI, but also at other locations such as an IWF or a Floor Control Server (such an offset should not be applied twice) .
  • a qualifier may be applied that indicates whether the value inserted was obtained by direct measurement or by estimation or configuration.
  • the interconnected systems may be configured with a target maximum acceptable timing delay for Floor Requests. If a Floor Request exceeds that level of timing delay, this may be flagged before it is forwarded to the controlling FCS.
  • This information may be used by the controlling system or FCS as input towards taking a decision to introduce queuing for the combined group, e.g. if that was not already supported, or to introduce particular queuing procedures to cope with a long latency group member.
  • one mechanism to carry a time-stamp to the Floor Control server is within the body of a Floor Request message issued by a device client. This is a relatively secure approach because the message body may be ciphered between the device client and the Mission Critical system, and not readable by untrusted intermediate networks below the Mission Critical application layer (such networks may include the SIP core if it is not operated by a trusted party) .
  • 3GPP specifications have introduced a number of optimisations to reduce signalling load across the network.
  • a group call is usually commenced with a SIP INVITE or alternative SIP message containing an SDP offer, and rather than require a separate message containing an explicit Floor Request, the 3GPP solution allows the SIP message to have a media level attribute "mc_implicit_request" to indicate that the message is also an implicit floor request.
  • the time-stamp may be introduced by modifying a SIP message that has the media level attribute that indicates an implicit Floor Request, to include a time-stamp in the body, which may optionally be ciphered using the same security key mechanism as used for an explicit Floor Request.
  • a time-stamp may be included as a media level attribute in the associated UDP stream for the floor control in the SDP offer/answer.
  • an alternative embodiment is to make use of the already existing SIP methods. Whilst the SIP Date field is of insufficient accuracy to cope with the millisecond level required for Mission Critical work, the SIP ‘Timestamp’ header field as described in RFC3261 contains sufficient accuracy to meet this level of accuracy, as does the ‘delay’ header field.
  • a network node may choose not to apply a time-stamp to a Floor Request message that passes through it if it detected that the message has already been time-stamped, or apply a time-stamp to those messages not already time-stamped.
  • the timestamps may also be used for system logging and performance auditing and analysis.
  • Figure 2 shows the architecture of a communications system according to an embodiment of the present invention.
  • a mission critical system 301 engaged in communications with another mission critical system 320 contains a Mission Critical Server 302 designated as the primary server for a particular group or private communication.
  • the Mission Critical Server 302 is operationally linked to a Floor Control Server 303 modified to handle the aspects of the invention, in particular a floor prioritisation and queuing policy that includes time of sending, or indicated time of sending, of an incoming floor request message.
  • the mission critical system 301 also contains a Group Management Server 304 that is responsible for issuing group management messages, including the distribution of security keys for the purpose of Group Management and similar tasks, and a Key Management Server 305 that supplies security keys, or master keys that enable the creation of more specific keys on a per-handset or per-group basis.
  • the Key Management Server 305 is operationally connected to the Group Management Server 304.
  • the Mission Critical System 301 is operationally connected to an Interworking Function (IWF) 310 that incorporates a Floor Control server proxy 311 and a Group Management Server proxy 312.
  • the Group Management Server 304 communicates with the Group Management Server proxy 312.
  • proxy is used to represent an entity that terminates messages as if it was either a server or a client and resends the message (possibly modified) as if it was a client or server respectively.
  • the format headers, the contents and transport mechanisms of such forwarded messages may be modified in transit by such proxies.
  • the Interworking Function 310 is registered with the primary Mission Critical System 301 as a member of any group or re-grouped/combined group that has members in both the primary system 301 and the other Mission Critical System 320, and as such contains a Group Management client as part of the Group Management Server Proxy 312. Group membership provides it with a URI that will receive Group Management and related security keys from the primary Group Management Server 304. This allows it to derive or calculate the necessary keys to read certain Group Management messages, including Floor Request and Floor Grant messages, as well as modify such messages.
  • the Group Management Server proxy 312 also acts a Group Management server towards the Group Management Server proxy 322 within the Other Mission Critical system 320. It does this by deciphering the keys received by its own Group Management client and encoding them in a message format suitable for use over the interface between the IWF 310 and the Other Mission Critical System 320 but replacing the source identity of the Group Management Server 304 with its own identity.
  • the Other Mission Critical system 320 does not have a formally defined Group Management server or proxy, and any ciphering and transport of keys between the IWF 310 and the Other Mission Critical System 320 may use different methods to those used in 3GPP Mission Critical systems. These methods may also include provisioning security keys for use in transporting messages from the IWF 310 toward the Other Mission Critical System 320.
  • TETRA Switching and Management Infrastructure
  • ISI Inter-System Interface
  • the IWF 310 may appear as another SwMI to the TETRA SwMI and create messages in a format compatible, or closely compatible with the ISI in order to minimise modifications to TETRA SwMIs supporting the ISI for intra-TETRA use.
  • the Other Mission Critical System 320 contains functions acting in the role of Floor Control Proxy 321 and a Group Management Proxy 322.
  • the Floor Control Proxy 321 acts to manage the floor for groups within the Other Mission Critical System 320. For a group or private call where there are members in both the primary Mission Critical System 301 and the Other Mission Critical System 302, it will act by forwarding the Floor Request Messages to the Interworking Function 310 and its Floor Control server proxy 311, which acts as the Floor Control Server for that call.
  • the Group Management proxy 312 receives Group Management keys from the Interworking Function 310 and distributes them to the members of the group currently being served by that Mission Control System, such as a mobile handset 330 containing a client function 331 to receive and transmit group management messages, including those related to Floor Control.
  • the client function 331 in the handset 330 has access to an accurate timing source in order to apply the time-stamp.
  • a particular aspect of the technology described herein is to introduce a mechanism to handle Floor Requests when the user device does not support time-stamping by the client during operation.
  • time sources are commonly available and used in communications networks, more general communications systems and the internet, and make use of techniques such as NTP (Network Time Protocol) or IEEE1588v2 P2P (Precision Time Protocol) to derive an absolute time value used within a communications network.
  • NTP Network Time Protocol
  • IEEE1588v2 P2P Precision Time Protocol
  • the primary Floor Control Server may also require an accurate time source in order to be able to estimate round trip times where this technique is used to estimate latency.
  • the time sources 340 are shown as one and the same, but it will be appreciated by one skilled in the art that the time sources may differ as long as any offset between the two is known or can be calculated.
  • the user time source (s) must be synchronised to the time sources 340, so as to take into account the time of travel between the time source 340 and the user.
  • Figure 3 shows a Message Sequence chart illustrating embodiments of the invention.
  • a device denoted Floor participant 1
  • a group on the 3GPP Mission Critical system designated the primary system for a particular group/regrouped call.
  • Another device denoted Floor participant 2
  • a second 3GPP Mission Critical system is connected to a second 3GPP Mission Critical system
  • a further device denoted Floor participant 3
  • step 1 a session is established with a group across more than one Mission Critical system.
  • the primary system has been established as a 3GPP MCPTT system.
  • three systems are shown in Figure 3: the primary 3GPP MCPTT system, a partner 3GPP MCPTT system, and a non-3GPP other system connected via an Interworking Function (IWF) .
  • IWF Interworking Function
  • Time-stamps have been provisioned with time offsets to include in Floor Request messages, either statically, or by dynamic calculation using one or more of the techniques described above (e.g. RTCP, Keep-alives, Heartbeat, DPD, ping) to calculate an offset based on deducing the one way delay from values including the round trip time (such as a halving the round trip time if the link is assumed symmetric) .
  • RTCP Keep-alives
  • Heartbeat DPD
  • ping ping
  • Such calculations may be applicable to both links in the application server domain, for example IWF to SwMI, as well as between a server and a device.
  • the parameter value may be updated dynamically, based on on-going measurements.
  • Such an option may be desirable in arrangements such as when a gateway cell of the type described above, or any other relaying node, changes position, or in the case that congestion in one of the links causes messaging delays.
  • step 2 at least two users across the systems wish to communicate within the group call and take action to initiate a floor request. This activity is conveyed to the clients on the device.
  • step 3 the handset clients cause their handsets to issue Floor Requests towards their respective Mission Critical server systems.
  • the handset client is able to apply a time-stamp itself (either in the ciphered message body or at SIP level) .
  • Steps 3 and 4 may happen concurrently and not in sequence because of the overlapping nature of the activities within each separate system.
  • Step 3a is applicable to the other MC system where neither the device nor the system core are able to apply a time-stamp.
  • a Floor Request message corresponding to the original Floor Request is sent from the other MC system to the Interworking Function
  • Step 3b is applicable at an infrastructure node configured to add an offset or time-stamp.
  • the infrastructure node As the infrastructure node has been configured to appear as part of the group, it has the necessary ciphering keys and as Floor Requests are ciphered on a hop by hop basis, the node has the ability to decipher, modify and re-cipher the Floor Request message as it passes through the node. This may be done to introduce a time-stamp or delay offset into the body of the message, or into the SIP header.
  • the time-stamp is set as a modified time of reception of the Floor Request by the node by subtracting from the time of reception an available estimate of the delay in transmission of the message before it arrived at the time-stamping node. Contributions and estimates to such a delay calculation are described above.
  • An alternative embodiment is to apply the time-stamp as the time-of reception, but to introduce a field that indicates the delay offset. If required by the protocol, the modified Floor Request message is then ciphered preparatory to forward transmission toward the primary Floor Control Server.
  • An indication of the source of the time information and the source and reliability of the delay offset may also be included.
  • step 4 nodes that have created a modified Floor Request message forward them to the primary Floor Control Server.
  • the primary Floor control server has received a set of Floor Request messages as a result of steps 3 and 4. It has been configured with a target latency to deliver a response to a Floor Request for group calls of this type, e.g. inter-system group calls.
  • the primary Floor control server examines the time-stamp and/or delay offset if the latter is included to determine a calculated time of transmission estimate, and compares this against the time of reception at the primary Floor Control Server.
  • the FCS is able to estimate the time of travel of the Floor Request message from source, and is optionally able to use this as an estimate of the time available for it to make a Floor Request decision before it has to send a response that will arrive within the configured target latency. If such an option is used then the available time limit may need to be reduced dynamically as new messages arrive within the allowable time window and a similar calculation is applied based on their estimated time of travel but which gives an earlier requirement for a Floor Request decision than the current time limit.
  • a Floor Request message will arrive with a time-stamp and estimated time of travel that implies that the current time limit to decide has already been exceeded if that requester is to receive a response within the desired target latency. In that case a decision should be taken immediately.
  • the Floor Control Server is able to apply its internally configured Floor Control arbitration algorithm to decide which of the received Floor Request messages is granted the Floor. In the case of two messages that are equal in other categories, the calculated time of transmission estimate is used to determine which message is given priority in the Floor grant.
  • the Floor Request messages are stored in a queue using their calculated times of transmission for use in any arbitration for Queue position and when the Floor next becomes free.
  • a modified queuing mechanism may be used in how such messages are prioritised.
  • step 6 the primary Floor Control server issues a Floor Grant message towards the device that made the successful request, via its Floor Control server or intermediate proxies.
  • step 7 any intermediate nodes between the primary Floor Control Server and the successful device forward the Floor Grant message to that device, possibly reformatting it in the case of inter-system access via an IWF.
  • step 8 the device that made the successful Floor Request receives its Floor Grant message and is able to transmit.
  • step 9 and step 10 the Floor Control Server and intermediate nodes send Floor rejected messages to those devices that did not make the successful Floor Request, and if queuing is possible, these devices also receive notification of their position in the queue.
  • Step 1 is carried out in a similar way to that described above.
  • the primary system being an LTE system in this case, and a TETRA system, connected via an Interworking Function.
  • a combined/regrouped group is set up containing devices on both systems.
  • step 2 users on devices on the TETRA network and the LTE network wish to communicate, and in step 3 they cause the devices to issue TETRA and LTE Floor Request messages respectively.
  • the TETRA request occurs at the TETRA device slightly before the LTE request.
  • the TETRA device is a standard device not enabled with time-stamping capability. Consequently it sends a U-TX DEMAND message as described in Table 2.
  • step 3 the handset in the LTE system is enabled with a time-stamping mechanism and sends a Floor Request message modified from current 3GPP specifications to include the time-stamp information.
  • the media stream has yet to start and so the Floor Request is a SIP INVITE with the implicit floor request as per 3GPP specification 24.379, which includes the "mc_implicit_request" media level attribute in the associated UDP stream for the floor control in the SDP offer/answer.
  • the SIP header includes a Timestamp, e.g.
  • Timestamp ⁇ xx>
  • ⁇ xx> represents a time such as NTP time.
  • step 3a the TETRA SwMI sends an ISI-TX_DEMAND message to the IWF in the format described in Table 3.
  • step 3b the IWF receives the ISI-TX_DEMAND message and converts it to a form suitable for use in an MCPTT system.
  • a particular embodiment is to use a SIP INVITE of a similar format as for the LTE system in step 3.
  • the SIP header field does not allow additional details about the time-stamp quality and source to be included, and so a more preferred option is to include further time-stamp qualifier options within the message body, such as in media level attributes in the associated media stream for the floor control in SDP offer/answer.
  • step 4 the primary Floor Control Server receives the Floor Request messages and acts as described above.
  • the time-stamp may be inserted by a TETRA SwMI before forwarding the Floor Request to the IWF as a modified ISI-TX_DEMAND message.
  • a possible realisation of a modified ISI-TX_DEMAND message to carry is shown in Table 5.
  • the IWF receives the Modified ISI-TX_DEMAND message, and appearing as a client to the primary system, creates a SIP INVITE message with the time-stamp carrying the “Tx request time” , and “Tx request time quality” , “Tx request outside time limit” service elements, appearing in the message body, such as in media level attributes for the Floor Control media stream.
  • a communications station can, in principal, send a floor request at any time, including when another party is speaking in the call.
  • the system may be configured such that requesting parties can only send their floor requests when notified by the communications system. Any floor requests that communications stations send while another communications station is transmitting to the group may be discarded.
  • the Floor Control Server when the Floor Control Server is notified by a communications station that it has finished transmitting to the group, the Floor Control Server will transmit to the communications stations of the group a notification indicating that the communications stations are now able to request the floor.
  • This transmission from the Floor Control Server may be known as a Transmit Ceased message, a permission to transmit message, a “Floor Idle” message, or another similar term.
  • the communications stations that are subject to a greater time delay will be at a disadvantage in being able to make a floor request, i.e. once the “transmit ceased” message arrives.
  • the system may send its communication indicating that communications stations can make floor requests to different communications station at different times, e.g. taking into account the varying time delays.
  • One or more communications stations that experience a greater transmission time delay to/from the transmitting source may have their messages sent at an earlier time compared to communications stations that experience a lesser transmission time delay.
  • the appropriate time delay can be determined using the time taken for a floor request to arrive from a communications station, e.g. in a particular part of the system infrastructure, or otherwise.
  • the system can make use of previously determined or configured estimates of time delays between parts of the system, including but not limited to estimates obtained via estimating the time delay of transmission requests (Floor Requests) , in order to determine the timing to be used when transmitting messages to the communications stations indicating that transmission has ceased.
  • Floor Requests time delay of transmission requests
  • An optional enhancement to this method is to take account of the network location of the communications stations in order to combine the permission to transmit messages for communications stations that are within a similar radio location in the system (e.g. within the same LTE Multimedia Broadcast and Multicast Services (MBMS) Service Area) into a single broadcast message, e.g. as opposed to individual unicast messages.
  • MBMS Multimedia Broadcast and Multicast Services
  • Another optional enhancement is for the controlling node (e.g. Floor Control Server) to send its permission to transmit messages at a suitably early time to those systems, or subsystems, containing group members or linked group members, marked with a time delay corresponding to the delay between that system or subsystem and a controlling node.
  • the systems or subsystems may then transmit the permission to transmit message to the communications stations that they serve after that time delay.
  • This has the advantage of preventing a distant sender from pressing the push to talk button on the communications station independently of receiving the permission to talk message, but slightly ahead of doing so, and thereby gaining an unexpected time advantage.
  • the present invention in its preferred embodiments at least, provides an improved mobile communications system. This is achieved, in the preferred embodiments of the present invention at least, by associating with a floor request information indicating the time at which the request was made, and using the information when determining whether the floor request should be granted.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
PCT/CN2018/071779 2017-01-06 2018-01-08 Mobile communications system WO2018127176A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201880000297.8A CN108541381B (zh) 2017-01-06 2018-01-08 移动通信系统

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GBGB1700236.1A GB201700236D0 (en) 2017-01-06 2017-01-06 Mobile communications system
GB1700236.1 2017-01-06

Publications (1)

Publication Number Publication Date
WO2018127176A1 true WO2018127176A1 (en) 2018-07-12

Family

ID=58463712

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/071779 WO2018127176A1 (en) 2017-01-06 2018-01-08 Mobile communications system

Country Status (3)

Country Link
CN (1) CN108541381B (zh)
GB (1) GB201700236D0 (zh)
WO (1) WO2018127176A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110691333A (zh) * 2019-10-11 2020-01-14 厦门睿洽科技有限公司 一种公网对讲方法
WO2020263580A1 (en) * 2019-06-26 2020-12-30 Motorola Solutions, Inc. Method and key management facility for managing keys of a single user having a plurality of mobile devices
CN114339724A (zh) * 2020-09-29 2022-04-12 成都鼎桥通信技术有限公司 应用于集群通信系统的集群通信方法、系统及存储介质

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114554425A (zh) * 2020-11-25 2022-05-27 北京中兴高达通信技术有限公司 4g和5g融合集群通信方法、系统、存储介质和电子装置
CN114554426A (zh) * 2020-11-25 2022-05-27 北京中兴高达通信技术有限公司 呼叫方法及装置、存储介质、电子装置
CN113315564B (zh) * 2021-04-23 2022-09-27 鲁义昌 一种双向可移动地空通信系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040196803A1 (en) * 2003-04-03 2004-10-07 Lg Electronics Inc. Apparatus and method for controlling access to network in wireless communication system
US20050141543A1 (en) * 2003-12-26 2005-06-30 Nec Corporation Competition avoidance control method for data transmission-reception system, data transmission-reception system, and terminal for data transmission-reception system

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7295853B2 (en) * 2004-06-30 2007-11-13 Research In Motion Limited Methods and apparatus for the immediate acceptance and queuing of voice data for PTT communications
CN102149050B (zh) * 2011-01-24 2013-09-18 北京邮电大学 PoC会话中对发言权进行移动队列控制的方法及系统
EP3314973B1 (en) * 2015-06-26 2019-10-23 Samsung Electronics Co., Ltd. Communication method in a terminal and terminal suitable for the same

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040196803A1 (en) * 2003-04-03 2004-10-07 Lg Electronics Inc. Apparatus and method for controlling access to network in wireless communication system
US20050141543A1 (en) * 2003-12-26 2005-06-30 Nec Corporation Competition avoidance control method for data transmission-reception system, data transmission-reception system, and terminal for data transmission-reception system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SAMSUNG: "Floor control for off-network MCPTT", 3GPP TSG-CT WGI MEETING #93 MCPTT CL-152899, 21 August 2015 (2015-08-21), XP050991271, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_93_Vancouver/docs/> *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020263580A1 (en) * 2019-06-26 2020-12-30 Motorola Solutions, Inc. Method and key management facility for managing keys of a single user having a plurality of mobile devices
US11218872B2 (en) 2019-06-26 2022-01-04 Motorola Solutions, Inc. Method and key management facility for managing keys of a single user having a plurality of mobile devices
CN110691333A (zh) * 2019-10-11 2020-01-14 厦门睿洽科技有限公司 一种公网对讲方法
CN114339724A (zh) * 2020-09-29 2022-04-12 成都鼎桥通信技术有限公司 应用于集群通信系统的集群通信方法、系统及存储介质
CN114339724B (zh) * 2020-09-29 2023-07-25 成都鼎桥通信技术有限公司 应用于集群通信系统的集群通信方法、系统及存储介质

Also Published As

Publication number Publication date
CN108541381B (zh) 2022-02-18
GB201700236D0 (en) 2017-02-22
CN108541381A (zh) 2018-09-14

Similar Documents

Publication Publication Date Title
WO2018127176A1 (en) Mobile communications system
US10085124B2 (en) System and method to leverage web real-time communication for implementing push-to-talk solutions
US7643817B2 (en) Method and apparatus for rapid secure session establishment on half-duplex AD-hoc group voice cellular network channels
WO2016112671A1 (zh) 一种集群通信系统、服务器及通信方法
US20080220765A1 (en) Control procedure for simultaneous media communications within a talk group in communication networks for public safety
WO2006124326A1 (en) Fast secure session on half-duplex voice network channels
US20140181312A1 (en) Systems and Methods for Peer-to-Peer IMS
EP1842388A1 (en) Method and system for guaranteeing seamless session when replacing poc terminal in poc system
US10367863B2 (en) Method for providing dynamic quality of service for push-to-talk service
CA2936083C (en) Optimized methods for large group calling using unicast and multicast transport bearers for push-to-talk-over-cellular (poc)
CN114557025A (zh) 关于针对上行链路流式传输服务的服务质量（qos）提示的考虑
US9510165B2 (en) Push-to-talk-over-cellular (PoC) service in heterogeneous networks (HETNETS) and multimode small cell environments
CA2599015A1 (en) A wireless communication system and method
KR20060014626A (ko) 발언권 제어의 최적화를 위한 피티티 서비스 시스템 및 방법
KR102347662B1 (ko) 무선 통신 시스템에서 서비스 제공 방법 및 장치
WO2016065036A1 (en) System for inter-communication between land mobile radio and push-to-talk-over-cellular systems
EP3216248B1 (en) Method and system for providing dynamic quality of service for push-to-talk service
EP3011767B1 (en) Sip extension for dmr networks matching pmr features
EP3183898A1 (en) Relay-mode and direct-mode operations for push-to-talk-over-cellular (poc) using wifi technologies
US20230007710A1 (en) Security mechanism for connection establishment over multi-hop sidelinks
EP3216176B1 (en) Architecture framework to realize push-to-x services using cloud-based storage services
Kurth et al. Frequency cross-coupling using the Session Initiation Protocol
Machalek et al. of Contract Seamless Communication for Crisis Management
Kurth et al. Advanced radio service features using the session initiation protocol

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18736508

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 05/11/2019)

122 Ep: pct application non-entry in european phase

Ref document number: 18736508

Country of ref document: EP

Kind code of ref document: A1