WO2017051503A1 - 通信システム、リレー端末、リモート端末及び通信制御方法 - Google Patents

通信システム、リレー端末、リモート端末及び通信制御方法 Download PDF

Info

Publication number
WO2017051503A1
WO2017051503A1 PCT/JP2016/003853 JP2016003853W WO2017051503A1 WO 2017051503 A1 WO2017051503 A1 WO 2017051503A1 JP 2016003853 W JP2016003853 W JP 2016003853W WO 2017051503 A1 WO2017051503 A1 WO 2017051503A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
remote
relay
voice data
communication node
Prior art date
Application number
PCT/JP2016/003853
Other languages
English (en)
French (fr)
Inventor
貴子 堀
星野　正幸
ヨアキム ローア
マリック プラティーク バス
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
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 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to JP2017541224A priority Critical patent/JPWO2017051503A1/ja
Publication of WO2017051503A1 publication Critical patent/WO2017051503A1/ja
Priority to US15/916,138 priority patent/US10420057B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/155—Ground-based stations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/24—Cell structures
    • H04W16/26—Cell enhancers or enhancement, e.g. for tunnels, building shadow
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/155—Ground-based stations
    • H04B7/15507—Relay station based processing for cell extension or control of coverage area
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/16—Communication-related supplementary services, e.g. call-transfer or call-hold
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16—Gateway arrangements

Definitions

  • the present disclosure relates to a communication system, a relay terminal, a remote terminal, and a communication control method.
  • MCPTT Mobility Critical Push To Talk
  • 3GPP 3rd Generation Partnership Project
  • Non-Patent Document 1 describes requirements for formulating details of MCPTT services and systems. According to Non-Patent Document 1, as an MCPTT service, an on-network service, an off-network service, or a service using both the on-network service and the off-network service is considered.
  • the on-network service uses an LTE (Evolved Packet System) consisting of LTE (Long Term Evolution) radio access network (eUTRAN: evolved Evolved Terrestrial Radio Access Network) and core network (EPC: Evolved Packet Core).
  • LTE Long Term Evolution
  • eUTRAN evolved Evolved Terrestrial Radio Access Network
  • EPC Evolved Packet Core
  • Non-Patent Document 2 and Non-Patent Document 3 in communication using GCSE_LTE, for each terminal (UE: User ⁇ Equipment) participating in a group service such as MCPTT, Non-Patent Document 10 or Non-Patent Document 11
  • the unicast communication using the EPS bearer described in 1) may be performed, or the MBMS communication using the MBMS (Multimedia Broadcast and Multicast Service) bearer described in Non-Patent Document 12 may be performed.
  • the off-network service is a service using ProSe (Proximity Service: for example, see Non-Patent Document 4, Non-Patent Document 5, Non-Patent Document 6, and Non-Patent Document 7) that is direct communication between terminals. Prose communication is sometimes called sidelink communication.
  • the UE-to-Network relay (relay) described in Non-Patent Document 1, Non-Patent Document 6, Non-Patent Document 9, etc. is used as a service using both the On-network service and the off-network service.
  • a service using UE-to-Network relay is a UE that exists within the coverage of the base station (eNB: eNode B), and a UE (remote UE) that is outside the eNB coverage and EPC It is a service that functions as a relay UE that relays communication with the.
  • an off-network service using ProSe communication is performed between the relay UE and the remote UE
  • an on-network service using GCSE_LTE is performed between the relay UE and the EPC.
  • the UE of the user who receives the MCPTT service belongs to the group of the MCPTT service. There may be a plurality of groups to which the UE belongs at the same time.
  • Non-Patent Document 8 and Non-Patent Document 9 disclose examples of MCPTT service architecture and signaling including registration with the MCPTT service group, control of the right to speak, resource allocation to the network, and the like. .
  • FIG. 1 is a view of a route through which an MCPTT service architecture using UE-to-Network relay and voice data (voice packet) can be considered from Non-Patent Document 1, Non-Patent Document 6, Non-Patent Document 9, and the like. An example is shown.
  • the MCPTT server (MCPTT Server) shown in FIG. 1 is a SIP (Session Initiation Protocol) server that performs registration of users participating in the MCPTT service or controls the MCPTT session, a floor control server (Floor Control Server) that controls the right to speak. It has a media distribution function (Media Distribution Function) for terminating voice data from a speaker once and transferring it to an MCPTT service participant, a ProSe function described in Non-Patent Document 6, and the like.
  • SIP Session Initiation Protocol
  • Floor Control Server Floor Control Server
  • UE1, UE2, UE3, UE4, and UE5 are UEs participating in the same MCPTT service, UE1 and UE2 are present in the eNB coverage, and UE3, UE4, and UE5 are eNB coverages. Exists outside. Further, UE2 has a function as a relay UE, and UE3, UE4, and UE5 participate in the MCPTT service via UE2 as a remote UE. In the example shown in FIG. 1, UE1 currently gives a floor (Floor Grant) and speaks, and UE2 to UE5 receive UE1's speech (voice packet).
  • Non-Patent Document 6 Non-Patent Document 9 and the like are used.
  • the relay UE assigns an IP address to the remote UE.
  • IP address is IPv4
  • the relay UE has a NAT (Network Address Translation) function for the remote UE.
  • NAT Network Address Translation
  • the remote UE performs user registration (registration) with the SIP server via the relay UE.
  • the remote UE sends INVITE, which is SIP call control signaling, to the SIP server, and starts MCPTT communication.
  • each of remote UEs UE3 to UE5 independently performs user registration with the MCPTT server and starts MCPTT communication independently.
  • the relay UE relays only the unicast communication packet from the EPC to the remote UE, and does not transfer the MBMS communication packet. That is, each remote UE needs to establish an EPS bearer with the EPC via the relay UE and perform unicast communication.
  • the MCPTT server duplicates the voice packets transmitted by UE1 to the MCPTT server for each of UE3, UE4, and UE5, and adds IP / UDP headers for each of UE3, UE4, and UE5.
  • UE2 which is relay UE in FIG. 1 transmits the packet sent to UE3, UE4, UE5 to UE3, UE4, UE5 using ProSe communication.
  • Non-Patent Document 6 Non-Patent Document 7, and Non-Patent Document 11
  • broadcast distribution to UEs assigned the same group ID (ProSe (Layer-2 Group ID) Is done. That is, when the same group ID is assigned to UE3, UE4, and UE5 participating in the same MCPTT service, packets sent to each of UE3, UE4, and UE5 are distributed to all of UE3, UE4, and UE5. Will be.
  • a UE when a UE receives a packet sent using broadcast delivery, the UE checks whether it is a packet addressed to itself and discards the packet if it is not addressed to itself. Do. However, for example, when an AMR (Adaptive MultiRate) or AMR-WB (AMR-WideBand), which is a 3GPP audio codec, is used for a voice packet, a packet is normally generated every 20 msec. The frequency of confirming the destination and discarding unnecessary packets increases. In addition, the larger the number of remote UEs to which the same group ID is assigned, the more packets the remote UE confirms / discards, and the processing load on the remote UE increases. Further, by transmitting many unnecessary packets from the relay UE to the remote UE, radio resources are wasted.
  • AMR Adaptive MultiRate
  • AMR-WB AMR-WideBand
  • One aspect of the present disclosure is to provide a communication system, a relay terminal, a remote terminal, and a communication control method that can suppress consumption of resources and radio resources of the core network while suppressing an increase in processing load of the relay UE. .
  • a communication system is a communication system in which a terminal to which a right to speak is given among a plurality of terminals transmits audio data to a communication node, and another terminal receives the audio data from the communication node.
  • the plurality of terminals include a relay terminal and a remote terminal that communicates with the communication node via the relay terminal, the remote terminal for registering the remote terminal as a user in the communication node.
  • the first signaling is transmitted, and the communication node detects a connection relationship between the remote terminal that has transmitted the first signaling and the relay terminal to which the remote terminal is connected, and is given the right to speak.
  • audio data is received from a terminal, only one of the relay terminal and the remote terminal having the connection relationship is connected to the audio data.
  • the voice data is transmitted using the unicast bearer for the destination terminal, and the relay terminal transmits the voice data transmitted from the communication node to the relay terminal. Send to all connected remote terminals.
  • a relay terminal is a communication system in which a terminal to which a right to speak is given among a plurality of terminals transmits voice data to a communication node, and another terminal receives the voice data from the communication node.
  • the voice data transmitted from the communication node using a unicast bearer for the destination terminal of the voice data, and the destination terminal is given the right to speak It is determined in the communication node when voice data is received from a terminal, and is any one of the relay terminal and a remote terminal connected to the relay terminal, and the remote terminal identifies the relay terminal A receiving unit that communicates with the communication node via the communication node, and sends the received voice data to all remote terminals connected to the relay terminal. It adopts a configuration comprising a transmission unit for, a.
  • a remote terminal is a communication system in which a terminal to which a right to speak is given among a plurality of terminals transmits voice data to a communication node, and another terminal receives the voice data from the communication node.
  • a remote terminal that communicates with the communication node via a relay terminal, wherein the remote terminal transmits a first signaling for user registration with the communication node, and is transmitted from the relay terminal.
  • the voice data transmission destination terminal that receives the voice data and is transmitted from the communication node is determined in the communication node when the voice data is received from the terminal that is granted the floor, the relay terminal, And any one of the relay terminals connected to the relay terminal, and the voice data is for the destination terminal.
  • is transmitted from the communication node to the relay terminal using two casting bearer employs a configuration comprising a reception section, a.
  • a communication control method is a communication in which a terminal to which a right to speak is given among a plurality of terminals transmits audio data to a communication node, and another terminal receives the audio data from the communication node.
  • a communication control method in a system wherein the plurality of terminals include a relay terminal and a remote terminal that communicates with the communication node via the relay terminal, and the remote terminal is used as the communication node.
  • the first signaling for user registration is transmitted, and the communication node detects a connection relationship between the remote terminal that has transmitted the first signaling and the relay terminal to which the remote terminal is connected, and When receiving voice data from a terminal to which the right is granted, among the relay terminal and the remote terminal having the connection relationship Only one terminal is determined as a destination terminal of the voice data, the voice data is transmitted using a unicast bearer for the destination terminal, and transmitted from the communication node in the relay terminal The voice data is transmitted to all remote terminals connected to the relay terminal.
  • FIG. 1 is a diagram illustrating a configuration example of a communication system according to the first embodiment.
  • FIG. 2 is a diagram illustrating a configuration example of the MCPTT server according to the first embodiment.
  • FIG. 3 is a diagram illustrating a configuration example of the relay UE according to the first embodiment.
  • FIG. 4 is a diagram illustrating a configuration example of a remote UE according to Embodiment 1.
  • FIG. 5 is a diagram showing a sequence chart of operations during remote UE registration processing according to Embodiment 1.
  • FIG. 6 is a diagram showing a sequence chart (case 1) of the operation during voice communication according to the first embodiment.
  • FIG. 7 is a diagram showing an operation at the time of voice communication according to Embodiment 1 by a sequence chart (Case 2).
  • FIG. 1 is a diagram illustrating a configuration example of a communication system according to the first embodiment.
  • FIG. 2 is a diagram illustrating a configuration example of the MCPTT server according to the first embodiment.
  • FIG. 8 is a sequence chart (Case 3) showing the operation during voice communication according to the first embodiment.
  • FIG. 9 is a diagram showing a sequence chart illustrating operations during voice communication according to the second embodiment.
  • FIG. 10 is a diagram illustrating an example of a MAC subheader for sidelink.
  • the packet source / destination is not specified as “unicast IP address”, “broadcast IP address / multicast address / ProSe Group IP multicast address”, etc. , Means unicast IP address.
  • the communication system according to the present embodiment employs the configuration shown in FIG.
  • the communication system according to the present embodiment includes at least an MCPTT server 100 (corresponding to a communication node), a relay UE 200, and a remote UE 300.
  • PDN GW Packet Data Network ⁇ ⁇ Gateway 400 and Serving GW shown in Fig. 1 are nodes described in Non-Patent Document 10, and are paths through which audio data passes in the case of one-to-one distribution.
  • eNB is a node described in the nonpatent literature 10 etc., and is a base station in EPS.
  • UE2 existing within the eNB coverage corresponds to the relay UE200
  • UE3 to UE5 existing outside the eNB coverage correspond to the remote UE300.
  • the MCPTT server 100 shown in FIG. 1 stores data for the SIP server that controls the UE registration or MCPTT session participating in the MCPTT service, the right control server that controls the right to speak, and the MCPTT service participants.
  • the SIP server that controls the UE registration or MCPTT session participating in the MCPTT service
  • the right control server that controls the right to speak
  • the MCPTT service participants Is assumed to have a media distribution function for transferring data, a ProSe function described in Non-Patent Document 6, etc., but in reality, these servers and functions should be distributed among nodes or functions having different names. Is also possible.
  • FIGS. 2 to 4 are block diagrams showing configuration examples of the MCPTT server 100, the relay UE 200, and the remote UE 300 shown in FIG.
  • the MCPTT server 100, the relay UE 200, and the remote UE 300 have functions as described in Non-Patent Documents 1 to 11 in addition to the configurations shown in FIGS. .
  • the MCPTT server 100 shown in FIG. 2 includes a reception unit 101, a detection unit 102, a storage unit 103, a determination unit 104, a packet generation unit 105, and a transmission unit 106.
  • the receiving unit 101 receives SIP signaling transmitted from the UE at the time of user registration with the SIP server of the UE, and receives SIP INVITE signaling transmitted from the UE at the start of communication of the MCPTT service. Moreover, the receiving part 101 receives the audio
  • the detection unit 102 uses SIP signaling at the time of user registration received from the reception unit 101 or information on UEs already registered, and the relationship between the relay UE 200 and the remote UE 300 participating in the same group service in the MCPTT service (Connection relation) is detected.
  • the storage unit 103 stores the relationship detected by the detection unit 102.
  • the determination unit 104 determines whether or not it is necessary to establish a bearer for the remote UE 300 when communication from the remote UE 300 is started. Further, the determination unit 104 determines a voice packet transmission destination UE based on information stored in the storage unit 103 (relationship between the relay UE 200 and the remote UE 300) during voice communication in the MCPTT service. For example, the determination unit 104 transmits only one UE out of the relay UE 200 (UE 2 in FIG. 1) and the remote UE 300 (UE 3 to UE 5 in FIG. 1) having the connection relationship stored in the storage unit 103. Decide on the destination UE.
  • the packet generation unit 105 generates a packet based on the determination result (determination of the transmission destination UE) in the determination unit 104, and the transmission unit 106 transmits the packet generated by the packet generation unit 105.
  • 3 includes a reception unit 201, a packet generation unit 202, and a transmission unit 203.
  • the reception unit 201 receives a signal transmitted from the remote UE 300 or a signal transmitted from the MCPTT server 100.
  • the packet generation unit 202 generates a packet using a signal received from the reception unit 201. For example, the packet generation unit 202 changes the header information of the voice packet so that all the remote UEs 300 connected to the relay UE 200 can receive the voice packet transmitted from the MCPTT server 100, and addresses the remote UE 300. A packet may be generated.
  • the transmission unit 203 transmits the packet generated by the packet generation unit 202.
  • reception unit 301 includes a reception unit 301, a determination unit 302, a processing unit 303, and a transmission unit 304.
  • the reception unit 301 receives SIP signaling at the time of user registration or communication start, or a voice packet at the time of communication.
  • the determining unit 302 determines whether the voice packet received from the receiving unit 301 is addressed to the own device. For example, when the voice packet transmitted from the relay UE 200 is a voice packet transmitted from the own device, the determining unit 302 determines that the voice packet is not addressed to the own device.
  • the processing unit 303 performs processing (for example, data transfer to an upper layer processing unit (not shown)) on the voice packet addressed to the own device. On the other hand, the processing unit 303 discards voice packets that are not addressed to the own device (for example, voice packets transmitted by the own device).
  • the transmission unit 304 transmits SIP signaling at the time of user registration or communication start, or a voice packet when a right to speak is given.
  • FIG. 5 is a sequence chart showing an example of an operation during the registration process of the remote UE 300 according to the present embodiment.
  • the remote UE 300 is UE3 to UE5 shown in FIG. 1
  • the relay UE 200 is UE2 shown in FIG.
  • the remote UE 300 is connected to the relay UE 200 as described in Non-Patent Document 9 and the like (step (hereinafter, referred to as “ST”) 101).
  • ST Non-Patent Document 9 and the like
  • an IP address or IP address prefix
  • Remote UE 300 performs a registration process using SIP signaling for MCPTT server 100 using the assigned IP address (or an IP address generated from the prefix of the assigned IP address) (ST102).
  • the remote UE 300 may explicitly include the information of the connected relay UE 200 in the SIP signaling of the registration process.
  • the remote UE 300 may include information of the connected relay UE 200 in a part of the SIP header, for example, a via header, or may be included in SDP (Session Description Protocol).
  • the remote UE 300 includes the group ID and the ProSe Group IP multicast address assigned together with the group ID described in Non-Patent Document 6, or both the group ID and the ProSe Group IP multicast address in the SIP signaling.
  • the relationship between the remote UE 300 and the relay UE 200 may be transmitted to the SIP server.
  • the relay UE 200 may be changed or added by the relay UE 200 for the SIP signaling of the registration process.
  • the relay UE 200 does not explicitly include the information of the connected relay UE 200 in the SIP signaling of the registration process, but the relay UE 200 explicitly indicates its own information in the SIP signaling of the registration process.
  • the relay UE 200 may include its own information in a part of the SIP header, such as a via header, or may be included in the SDP.
  • the relay UE 200 transmits the relationship between the remote UE 300 and the relay UE 200 to the SIP server by adding the above group ID or ProSeProGroup IP multicast address or both the group ID and ProSe Group IP multicast address to the SIP signaling. May be.
  • the SIP signaling of the registration process is not limited to the case where it is directly transmitted from the remote UE 300 to the MCPTT server 100.
  • SIP signaling for registration processing is transmitted from the remote UE 300 to the relay UE 200, and once terminated at the relay UE 200, the relay UE 200 newly generates SIP signaling for registration processing for the remote UE and transmits it to the MCPTT server 100. May be.
  • the relay UE 200 does not explicitly include the information of the relay UE 200 connected to the remote UE 300 in the SIP signaling of the registration process generated by the remote UE 300, but the relay UE 200 includes the information of the own device for the remote UE. May be explicitly included in the SIP signaling of the registration process.
  • the relay UE 200 may include its own information in a part of the SIP header, such as a via header, or may be included in the SDP.
  • the relay UE 200 adds the group ID and the ProSe Group IP multicast address described in Non-Patent Document 6 or both the group ID and the ProSe Group IP multicast address to the SIP signaling, thereby relaying with the remote UE300.
  • the relationship of the UE 200 may be communicated to the SIP server.
  • detecting unit 102 when receiving unit 101 receives SIP signaling for registration processing, detecting unit 102 has a relationship (connection relationship) between remote UE 300 that has transmitted the SIP signaling and relay UE 200 to which remote UE 300 is connected. Is detected (ST103).
  • a method for detecting the relationship between the relay UE 200 and the remote UE 300 for example, information on the relay UE 200 included in SIP signaling may be used, or comparison of IP addresses with other remote UEs 300 already registered may be used. Good.
  • the detection unit 102 may detect the relationship between the relay UE 200 and the remote UE 300 by comparing the IP address (in the case of IPv4) or the prefix of the IP address (in the case of IPv6). .
  • the MCPTT server 100 inquires the information of the relay UE 200 that has already been registered, and the information included in the via header is really relayed. You may confirm whether it is the information of UE200.
  • the SIP signaling includes a group ID or a ProSe Group IP multicast address, or both a group ID and a ProSe Group IP multicast address
  • the MCPTT server 100 uses this information to identify the remote UE 300 and its remote A relationship (connection relationship) with the relay UE 200 to which the UE 300 is connected may be detected.
  • the detection unit 102 of the MCPTT server 100 indicates that UE2 is a relay UE200 and UE3, UE4, and UE5 are UE2. The relationship that it is a connected remote UE 300 is detected.
  • the storage unit 103 of the MCPTT server 100 stores information indicating the relationship between the relay UE 200 and the remote UE 300 detected by the detection unit 102 in ST103 (ST104).
  • the storage unit 103 also stores information on the group ID and ProSe Group IP multicast address.
  • the remote UE 300 performs communication start processing for the MCPTT service (ST105). For example, the remote UE 300 transmits SIP INVITE signaling to the MCPTT server 100.
  • the determination unit 104 of the MCPTT server 100 determines whether it is necessary to establish (or update) a bearer (unicast bearer) for the remote UE 300 that has transmitted the SIP INVITE signaling (ST106).
  • the determination unit 104 transmits the remote UE 300 to the PDN GW 400 through a PCRF (Policy and Charging Rules Function, not shown) as described in Non-Patent Document 10
  • PCRF Policy and Charging Rules Function, not shown
  • PDN GW 400 Upon receiving the request for bearer establishment for remote UE 300, PDN GW 400 establishes (updates) an EPC bearer for remote UE 300 (ST108).
  • the determination unit 104 is based on information stored in the storage unit 103 (relationship between the relay UE 200 and the remote UE 300) and is necessary for updating an existing bearer or newly establishing a bearer (for example, non-patent It is determined whether or not TFT (Traffic Flow Template) described in Document 10 etc. is set.
  • the determination unit 104 may use other information at the time of this determination, for example, information such as an operator policy preset in the MCPTT server 100 or the like.
  • the determination unit 104 may add the TFT for the remote UE 300 to the EPS bearer.
  • the determination unit 104 adds an uplink (direction from the UE to the PDN GW 400) TFT (ULFTTFT).
  • UFTTFT uplink TFT
  • determination section 104 adds a downlink TFT (DL TFT) only when sending a packet addressed to remote UE 300 and sends a packet addressed to remote UE 300. If not, it may be determined not to add a downstream TFT.
  • the determination unit 104 may use the unicast IP address of the remote UE 300 as the transmission destination IP address of the TFT, or may use ProSe Group IP multicast address.
  • the determination unit 104 may newly establish a voice packet EPS bearer for the remote UE 300. In this case, the determination unit 104 sets an uplink TFT. On the other hand, regarding the downlink, the determination unit 104 determines that a downlink TFT is set only when a packet addressed to the remote UE 300 is transmitted, and does not set a downlink TFT when a packet addressed to the remote UE 300 is not transmitted. May be. Further, when setting the downlink TFT, the determination unit 104 may use the unicast IP address of the relay UE 200 or the remote UE 300 as the transmission destination IP address of the TFT, or may use ProSe Group IP multicast address. .
  • the determination unit 104 receives the voice packet by MBMS and the relay UE 200 does not establish an EPS bearer for unicast reception (downlink) of the voice packet (or when TFT is not set). May be determined to simultaneously establish a downlink EPS bearer for relay UE 200 (or set a TFT) and add a TFT for remote UE 300 as described above. Further, when setting the downlink TFT, the determination unit 104 may use the unicast IP address of the relay UE 200 or the remote UE 300 as the transmission destination IP address of the TFT, or may use ProSe Group IP multicast address. .
  • the determination unit 104 receives the voice packet by MBMS and the relay UE 200 does not establish an EPS bearer for unicast reception (downlink) of the voice packet (or when TFT is not set). Alternatively, it may be determined that the bearer for the remote UE 300 is established as described above without establishing the downlink EPS bearer for the relay UE 200 (or setting the TFT). Further, when setting the downlink TFT, the determination unit 104 may use the unicast IP address of the remote UE 300 as the transmission destination IP address of the TFT, or may use ProSe Group IP multicast address.
  • this EPS bearer establishment process may be performed after the registration process.
  • the bearer establishment performed after the registration process is, for example, SIP signaling bearer establishment.
  • a UE other than the relay UE 200 (UE2) and the remote UE 300 (UE3 to UE5) receives a floor grant from the MCPTT server 100. Will be described.
  • FIG. 6 is a sequence chart showing an example of the operation of voice packet communication processing according to Case 1.
  • the receiving unit 101 of the MCPTT server 100 receives an uplink voice packet (voice packet transmitted from a UE to which a floor is given (UE1 in FIG. 1)) (ST201).
  • the determination unit 104 of the MCPTT server 100 transmits to which UE as a destination of the voice packet based on the information stored in the storage unit 103 (relationship between the relay UE 200 and the remote UE 300). Judgment is made (ST202). Specifically, the determination unit 104 determines only one UE of the relay UE 200 and the remote UE 300 in the above relationship stored in the storage unit 103 as the audio data transmission destination UE. In this determination, the determination unit 104 may use other information, for example, information such as an operator policy preset in the MCPTT server 100 or the like.
  • the determination unit 104 does not transmit a packet to the remote UE 300 subordinate to the relay UE 200 (UE 2), like the UE 3 to UE 5 illustrated in FIG. 1, and instead the relay UE 200 (to which the remote UE 300 is connected). It is determined that a packet is transmitted to UE2).
  • the determination unit 104 may determine to transmit a packet to one UE of remote UEs 300 connected to the relay UE 200 and receiving the same MCPTT service. That is, the determination unit 104 determines only the relay UE 200 or one remote UE 300 as a transmission destination UE without using each of the plurality of UEs as a transmission destination for a plurality of UEs including the relay UE 200 and the remote UE 300.
  • the determination unit 104 may determine to transmit a packet addressed to the ProSe Group IP multicast address that is assigned only to the relay UE 200 and the remote UE 300 or the remote UE 300.
  • determination section 104 determines the transmission destination UE (destination) so as to match the content of the EPS bearer established in FIG.
  • the determination unit 104 uses the downlink TFT transmission destination IP address (for example, the unicast IP address of the relay UE 200 or the remote UE 300, or ProSe Group IP multicast address) set in ST106 of FIG. Determine the destination UE.
  • the packet generation unit 105 of the MCPTT server 100 generates a downlink packet based on the determination result of the determination unit 104 (ST203). That is, the packet generation unit 105 generates a voice packet to which header information destined for the transmission destination UE determined by the determination unit 104 or header information destined for ProSe Group IP multicast address is added.
  • the generated packet (downlink) is transmitted to transmission destination UE (relay UE 200 in FIG. 6; UE 2 in FIG. 1) via transmission section 106 (ST204).
  • the transmitted packet is transmitted using the EPS bearer (unicast) established or updated in FIG.
  • the reception unit 201 of the relay UE 200 receives the voice packet transmitted from the MCPTT server 100 (ST204). Alternatively, the relay UE 200 intercepts the voice packet even when the destination of the voice packet is addressed to the remote UE 300. The relay UE 200 determines whether or not the received signal is a voice packet based on the EPS bearer QCI (QoS Class Identifier; described in Non-Patent Document 10). When the destination of the received voice packet or the intercepted voice packet is destined for the unicast IP address of the relay UE 200 or the remote UE 300, the reception unit 201 of the relay UE 200 outputs this voice to the packet generation unit 202. In addition, when the destination of the received voice packet is ProSe Group IP multicast address, the receiving unit 201 does not output the voice packet to the packet generation unit 202 but transmits it via the transmission unit 203.
  • EPS bearer QCI QoS Class Identifier
  • the packet generation unit 202 changes the header information of the voice packet received from the reception unit 201 so that all remote UEs 300 to which the same group ID is assigned can receive the voice packet addressed to itself (each remote UE 300). Then, a packet for the remote UE 300 is generated (ST205).
  • the packet generator 202 rewrites the IP header of the received voice packet with a broadcast address or a multicast address.
  • a multicast address it is necessary to perform the process regarding multicast group participation between relay UE200 and remote UE300 until remote UE300 completes a communication start process.
  • relay UE200 may negotiate previously with remote UE300 regarding the transmission destination port number used for transmission of an audio
  • ProSe Group IP multicast address may be used as the destination address.
  • the packet generated by the packet generation unit 202 (packet addressed to the remote UE 300) is transmitted via the transmission unit 203 (ST206).
  • relay UE200 transmits the audio
  • the relay UE 200 when there is one remote UE 300 connected to the own device, the relay UE 200 does not use a broadcast address or a multicast address, ProSe Group IP multicast address, or the like, and sends a packet to the remote UE 300 unicast address. May be sent.
  • the reception unit 301 of the remote UE 300 receives the packet transmitted from the relay UE 200 (ST206).
  • the determination unit 302 of the remote UE 300 determines whether or not to process the received packet (for remote UE) (ST207). Specifically, the determination unit 302 determines whether or not the received packet is a voice packet addressed to itself, from the packet header information. For the determination of the voice packet in the determination unit 302, a priority for each packet (PPP: “Per” Packet “Priority”) described in Non-Patent Document 13 or the like may be used. In addition, when the determination unit 302 confirms that the user has no right to speak or that other UEs have the right to speak, the determining unit 302 generates the received voice data. It is determined that the audio data is not transmitted.
  • PPP Per” Packet “Priority”
  • the determination unit 302 determines that the received packet is to be processed because the received packet is a voice packet addressed to the own device and the right to speak is not given to the own device.
  • the processing unit 303 of the remote UE 300 processes the packet based on the determination of the determination unit 302. For example, as shown in FIG. 6, when the determination result of the determination unit 302 is a determination that the packet is addressed to the own device and is not a packet generated / transmitted by the own device, the processing unit 303 displays the received packet. A process of receiving and passing data (RTP packet) to an upper layer (RTP layer) is performed (ST208).
  • RTP packet receiving and passing data
  • RTP layer an upper layer
  • FIG. 7 is a sequence chart showing an example of the operation of the voice packet communication processing according to Case 2.
  • the same processes as those in FIG. 6 are denoted by the same reference numerals, and the description thereof is omitted.
  • the remote UE 300 generates a voice packet and transmits the voice packet (uplink) to the MCPTT server 100 via the relay UE 200 (ST301).
  • the voice packet (uplink) is transmitted to the remote UE 300 that has not been granted the right to speak, to which the same group ID is assigned.
  • the processing unit 303 determines that the voice packet is not addressed to itself and discards the packet.
  • the MCPTT server 100 receives the uplink voice packet transmitted from the relay UE 300 (ST301), the destination UE (relay UE 200 or one remote UE 300 or ProSe Group IP multicast address of the voice packet)
  • the destination UE group is determined (ST202), a downlink packet is generated (ST203), and the packet (downlink) is transmitted (ST204).
  • the determination unit 104 of the MCPTT server 100 determines that the UE that has transmitted the packet is the remote UE 300 based on the information in the storage unit 103, and the remote UE 300 is the only remote UE 300 connected to the relay UE 200. And when relay UE200 does not need to receive this packet (for example, when relay UE200 has received the audio
  • relay UE 200 receives the voice packet transmitted from MCPTT server 100 (ST204), and changes the header information of the voice packet so that remote UE 300 under its control can receive the voice packet ( (ST205)
  • the generated remote UE packet is transmitted (ST206).
  • the reception unit 201 of the relay UE 200 does not output the voice packet to the packet generation unit 202 but transmits it via the transmission unit 203.
  • the determination unit 302 of the remote UE 300 determines whether or not to process the received packet (for remote UE) (ST207). Specifically, the determination unit 302 determines whether or not the received packet is a voice packet addressed to itself, from the packet header information. In addition, when the determination unit 302 confirms that the right to speak is not currently given to the own device or that the right to speak is given to another UE, the own device generates and transmits the received voice data. It is determined that the voice data is not the same.
  • the determination unit 302 is a packet addressed to the own device, since the right to speak is given to the own device, the determination unit 302 determines that the received packet is a voice packet generated and transmitted by the own device. That is, the determination unit 302 determines to discard the received packet without performing processing.
  • the processing unit 303 of the remote UE 300 processes the packet based on the determination of the determination unit 302. In FIG. 7, since it is determined that the received packet is a voice packet generated / transmitted by itself, processing section 303 performs processing for discarding the voice packet (ST302).
  • FIG. 8 is a sequence chart showing an example of the operation of the voice packet communication processing according to Case 3.
  • the remote UE 300 generates a voice packet destined for a broadcast address, a multicast address, or ProSe Group IP multicast address, and transmits it to the relay UE 200 and the remote UE 300 having the same group ID (ST401).
  • the determination unit 302 of the remote UE 300 that has not obtained the right to speak determines that the packet is a voice packet addressed to itself, and the processing unit 303 accepts the received packet and transfers the data (RTP packet) to the upper layer ( RTP layer) process.
  • the reception unit 201 of the relay UE 200 receives the voice packet transmitted from the remote UE 300 (ST401).
  • the relay UE 200 determines whether or not the received signal is a voice packet based on Per Packet Priority described in Non-Patent Document 13. Then, the reception unit 201 of the relay UE 200 outputs the received voice packet to the packet generation unit 202.
  • the packet generation unit 202 performs necessary processing such as changing the destination of the header of the voice packet received from the reception unit 201 to the MCPTT server 100, and generates a packet having the remote UE 300 as a transmission source and the MCPTT server 100 as a transmission destination. (ST402).
  • the packet generated by the packet generation unit 202 (packet addressed to the MCPTT server 100) is transmitted via the transmission unit 203 (ST403).
  • relay UE200 transmits the voice packet transmitted from remote UE300 to MCPTT server 100.
  • MCPTT server 100 When MCPTT server 100 receives the uplink voice packet transmitted from relay UE 200 (ST403), determination unit 104 of MCPTT server 100 determines that the UE that transmitted the packet is remote UE 300 based on the information in storage unit 103.
  • the UE having the same group ID may determine that the voice packet has already been received, and may determine not to transmit the packet to relay UE 200 or remote UE 300 (ST404).
  • the MCPTT server 100 maintains the relationship between the relay UE 200 and the remote UE 300 in the UE participating in the MCPTT group service. And at the time of voice communication, the MCPTT server 100 transmits a voice packet only to the relay UE 200 (or any one UE of the remote UE 300) or a UE group whose destination is ProSe Group IP multicast address. Then, relay UE 200 transmits the received voice packet to remote UE 300 under its control.
  • the relay UE 200 distributes the voice packet transmitted from the MCPTT server 100 to one UE to all the remote UEs 300 (UEs to which the same group ID is assigned) under its own control. Thereby, even in the ProSe communication between the relay UE 200 and the remote UE 300, it is possible to prevent the radio resources from being consumed wastefully without distributing packets for each UE to all UEs.
  • the relay UE 200 only has to distribute the voice packet transmitted from the MCPTT server 100 to all the remote UEs 300 to which the same group ID is assigned, and it is not necessary to manage the group ID for each remote UE 300. An increase in processing load on the UE 200 can be suppressed.
  • the present embodiment in the MCPTT service, it is possible to suppress the consumption of core network resources and radio resources while suppressing an increase in the processing load of the relay UE 200.
  • the ProSe function in the MCPTT server 100 gives a Layer 2 ID (hereinafter referred to as a direct communication ID) necessary for direct communication in UE-to-Network relay to the relay UE 200 and the remote UE 300 in addition to the group ID. .
  • the direct communication ID may be distributed when the relay UE 200 and the remote UE 300 are in a relationship between the relay UE and the remote UE, or may be distributed in advance before the relationship between the relay UE and the remote UE is established.
  • this direct communication ID may be an ID that is given without duplication to all UEs participating in the same MCPTT service, or that is given without duplication between a relay UE and a remote UE connected to the same relay UE. It may be.
  • the direct communication ID may be given to the remote UE by the relay UE instead of the ProSe function in the MCPTT server 100.
  • the direct communication ID may be a ProSe UE ID described in Non-Patent Document 6.
  • FIG. 9 is a sequence chart showing an example of the operation of the voice packet communication processing according to the present embodiment.
  • the receiving unit 101 of the MCPTT server 100 receives an uplink voice packet (voice packet transmitted from a UE to which a floor is given (UE1 in FIG. 1)) (ST501).
  • the determination unit 104 of the MCPTT server 100 determines to send the voice packet to all UEs that receive the downlink voice packet by the EPS bearer other than the UE that transmitted the uplink voice packet. (ST502). This determination is the same even if the source of the uplink voice packet is the remote UE 300.
  • the packet generation unit 105 of the MCPTT server 100 generates a downlink packet based on the determination result of the determination unit 104 (ST503).
  • the generated packet (downlink) is transmitted to the transmission destination UE via transmission section 106 (ST504).
  • Receiving section 201 of relay UE 200 receives the voice packet transmitted from MCPTT server 100 (ST504).
  • the packet generation unit 202 of the relay UE 200 generates a packet for the remote UE 300 using the direct communication ID (ST505). Specifically, the packet generation unit 202 performs Layer 2 processing as described in Non-Patent Document 11 and Non-Patent Document 7 so that the IP address of the remote UE 300 matches the direct communication ID of the remote UE 300. Note that the exchange (exchange) of the direct communication ID between the relay UE 200 and the remote UE 300 may be performed when the remote UE 300 discovers and connects to the relay UE 200. As described above, the remote UE 300 When connecting to the relay UE 200, the relay UE 200 may directly assign a communication ID to the remote UE 300.
  • FIG. 10 shows a sidelink MAC (Medium Access Control) subheader described in Non-Patent Document 7.
  • the packet generation unit 202 inputs the direct communication ID associated with the IP address of the remote UE 300 or a part thereof instead of the group ID in the DST column shown in FIG.
  • the relay UE 200 may change the size of the DST column if the size of the direct communication ID (or part thereof) does not match 16 bits as shown in FIG.
  • the relay UE 200 may set the value in the V column (MAC PDU format version number) shown in FIG. 10 for direct communication in order to distinguish from communication using a normal group ID.
  • the relay UE 200 may use the direct communication ID of the relay UE 200 with respect to the SRC field. If the size of the direct communication ID does not match 24 bits, the size of the SRC field is changed. Also good.
  • an entirely new MAC subheader may be defined for direct communication.
  • the packet transmitted from the transmission unit 203 of the relay UE 200 is received by the reception unit 301 of the remote UE 300 (ST506).
  • the MAC sublayer of remote UE 300 confirms that it is addressed to its own device by the direct communication ID of the destination, and performs reception processing (ST507).
  • the direct communication process described above is the same when packet transmission is performed from the remote UE 300 to the relay UE 200.
  • the mechanism for example, see FIG. 7 for discarding the packet transmitted by the own device may be applied in group communication using broadcast or multicast.
  • the communication system may be applied to packets other than voice packets, for example, floor control packets. Good. Further, the present invention may be applied to packets of media (video etc.) other than voice.
  • MCPTT has been described as an example.
  • the present invention may be applied to other services using a similar architecture.
  • each functional block used in the description of the above embodiments is typically realized as an LSI that is an integrated circuit having an input terminal and an output terminal.
  • the integrated circuit may control each functional block used in the description of the above embodiment, and may include an input terminal and an output terminal. These may be individually made into one chip, or may be made into one chip so as to include a part or all of them.
  • the name used here is LSI, but it may also be called IC, system LSI, super LSI, or ultra LSI depending on the degree of integration.
  • the method of circuit integration is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable / processor that can reconfigure the connection or setting of circuit cells inside the LSI may be used.
  • One embodiment of the present disclosure is useful for a communication system that provides MCPTT service and a user terminal that uses the communication system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)
  • Telephonic Communication Services (AREA)

Abstract

リモートUE（３００）は、当該リモートUE（３００）をMCPTTサーバ（１００）にユーザ登録するための第１シグナリングを送信し、MCPTTサーバ（１００）は、第１シグナリングを送信したリモートUE（３００）と、当該リモートUE（３００）が接続しているリレーUE（２００）との接続関係を検出し、発言権が与えられたUEから音声データを受信した場合、接続関係を有するリレーUE（２００）及びリモートUE（３００）のうち何れか１つのUEのみを音声データの送信先UEに決定し、送信先UE用のユニキャストベアラを用いて、音声データを送信し、リレーUE（２００）は、MCPTTサーバ（１００）から送信される音声データを、当該リレーUE（２００）に接続された全てのリモートUE（３００）へ送信する。

Description

通信システム、リレー端末、リモート端末及び通信制御方法
　本開示は、通信システム、リレー端末、リモート端末及び通信制御方法に関する。
　現在、３ＧＰＰ（3rd Generation Partnership Project）において、MCPTT（Mission Critical Push To Talk）の標準化が進められている。
　非特許文献１には、MCPTTのサービス及びシステムの詳細を策定する上での要求条件が記載されている。非特許文献１によると、MCPTTのサービスとしては、on-networkサービス、off-networkサービス、又は、on-networkサービス及びoff-networkサービスの両方を使用したサービスが考えられている。
　on-networkサービスは、LTE（Long Term Evolution）の無線アクセスネットワーク（eUTRAN：evolved Evolved Universal Terrestrial Radio Access Network）とコア網（EPC: Evolved Packet Core）とから成るEPS（Evolved Packet System）を利用して通信を行う、GCSE_LTE（Group Communication System Enablers for LTE：例えば、非特許文献２及び非特許文献３を参照）を使用したサービスである。非特許文献２及び非特許文献３によると、GCSE_LTEを用いた通信では、MCPTT等のグループサービスに参加している各端末（UE:User Equipment）に対して、非特許文献１０又は非特許文献１１に記載のEPSベアラを用いたユニキャスト通信を行ってもよく、非特許文献１２に記載のMBMS（Multimedia Broadcast and Multicast Service）ベアラを用いたMBMS通信を行ってもよい。
　また、off-networkサービスは、端末間直接通信であるProSe（Proximity Services：例えば、非特許文献４、非特許文献５、非特許文献６、非特許文献７を参照）を使用したサービスである。Prose通信は、サイドリンク（Sidelink）通信と呼ばれることもある。
　On-networkサービス及びoff-networkサービスの両方を使用したサービスとして、例えば、非特許文献１，非特許文献６，非特許文献９などに記載されているUE-to-Networkリレー（relay）を使用したサービスがある。UE-to-Networkリレーを使用したサービスとは、基地局（eNB：eNode B）のカバレッジ（coverage）内に存在するUEが、eNBのカバレッジ外に存在するUE（リモート（remote）UE）とEPCとの通信を中継するリレー（relay）UEとして機能するサービスである。このサービスでは、リレーUEとリモートUEとの間ではProSe通信を用いたoff-networkサービスが行われ、リレーUEとEPCとの間ではGCSE_LTEを用いたon-networkサービスが行われる。
　また、非特許文献１によると、MCPTTサービス提供を受けるユーザのUEは、MCPTTサービスのグループに所属する。UEが所属するグループは同時に複数であってもよい。
　MCPTTサービスでは、発言権制御（Floor Control）をサポートする事が要求されており、グループ内で発言権（Floor grant）を与えられたユーザのみが発言することが許される。また、この発言権が与えられる時間に制限をつけてもよい。また、緊急事態発生時などには、優先割込み（Pre-emption）を許可する事が要求されている。優先割込みが発生した場合には、現行のMCPTTサービスは一時中断され、発言権を優先割込みに譲る。非特許文献８及び非特許文献９には、MCPTTサービスグループへの登録、発言権制御、ネットワークへのリソース割当などを含むMCPTTサービスのアーキテクチャ（architecture）及びシグナリング（signaling）の例が開示されている。
　図１は、非特許文献１，非特許文献６，非特許文献９などより考えられる、UE-to-Networkリレーを用いたMCPTTサービスのアーキテクチャ（architecture）及び音声データ（音声パケット）の通る経路の一例を示している。
　図１に示すMCPTTサーバ（MCPTT Server）は、MCPTTサービスに参加するユーザの登録又はMCPTTセッションの制御を行うSIP（Session Initiation Protocol）サーバ、発言権制御を行う発言権制御サーバ（Floor Control Server）、発言者からの音声データを一旦終端し、MCPTTサービス参加者に転送するメディア配布機能（Media Distribution Function），非特許文献６に記載のProSe機能などを有する。これらのサーバ及び機能は別の名称を持つ他のノードに分散して存在する可能性もあるが、本開示では図の簡略化のため、MCPTTサーバの機能の一部として存在すると仮定する。
　図１において、UE1，UE2，UE3，UE4，UE5は同一のMCPTTサービスに参加しているUEであり、UE1及びUE2はeNBのカバレッジ内に存在しており、UE3，UE4，UE5はeNBのカバレッジ外に存在している。また、UE2はリレーUEとしての機能を有し、UE3，UE4，UE5はリモートUEとしてUE2を介してMCPTTサービスに参加している。図１に示す例では、現在、UE1が発言権（Floor Grant）を与えられて発言し、UE2～UE5がUE1の発言（音声パケット）を受信している。
　また、リレーUE（UE2）にリモートUE（UE3，UE4，UE5）が接続する際、非特許文献６及び非特許文献９などに記載された以下の手順が用いられる。
　１．リレーUEはリモートUEにIPアドレスを割り当てる。IPアドレスがIPv4の場合、リレーUEは、リモートUEに対してNAT（Network Address Translation）の機能を有する。
　２．リモートUEはリレーUE経由でSIPサーバに対してユーザ登録（registration）を行う。
　３．リモートUEはSIPサーバにSIP呼制御シグナリングであるINVITEを送り、MCPTTの通信を開始する。
3GPP TS 22.179 v13.2.0、 "Mission Critical Push to Talk (MCPTT) over LTE; Stage 1" 3GPP TS 22.468 v13.0.0、 "Group Communication System Enablers for LTE (GCSE_LTE)" 3GPP TS 23.468 v13.1.0、 "Group Communication System Enablers for LTE (GCSE_LTE); Stage 2" 3GPP TS 22.278 v13.2.0、 "Service requirements for the Evolved Packet System (EPS)" 3GPP TR 23.713 v1.5.0、 "Study on extended architecture support for proximity services" 3GPP TS 23.303 v13.0.0、 "Proximity-based services (ProSe); Stage 2" 3GPP TR 36.321 v12.6.0、 "Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification" 3GPP TR 23.779 v1.1.0、 "Study on application architecture to support Mission Critical Push To Talk over LTE (MCPTT) services" 3GPP TS 23.179 v0.3.0、 "Functional architecture and information flows to support mission critical communication services; Stage 2" 3GPP TS 23.401 v13.3.0、 "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access" 3GPP TS 36.300 v13.0.0、 "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2" 3GPP TS 23.246 v13.1.0、 "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description" 3GPP S2-151810，"LS reply on ProSe Priorities"
　図１に示す例では、リモートUEであるUE3～UE5の各々は、独立してMCPTTサーバにユーザ登録を行い、独立してMCPTT通信を開始している。
　また、非特許文献６によると、リレーUEは、EPCからのユニキャスト通信のパケットのみをリモートUEに対して転送（relay）し、MBMS通信のパケットを転送しない。すなわち、各リモートUEはリレーUE経由でEPCとの間にEPSベアラを確立し、ユニキャスト通信を行う必要がある。
　したがって、図１に示す例では、MCPTTサーバは、UE1がMCPTTサーバに送信した音声パケットを、UE3，UE4，UE5それぞれに対して複製し、UE3，UE4，UE5それぞれのIP/UDPヘッダを付加して送信する。また、図１においてリレーUEであるUE2は、ProSe通信を用いて、UE3，UE4，UE5それぞれに送られたパケットをUE3，UE4，UE5に送信する。
　しかしながら、非特許文献６、非特許文献７、非特許文献１１によると、ProSe通信では、同一のグループID（ProSe Layer-2 Group ID）が割り当てられているUEに対して同報配信（broadcast）が行われる。すなわち、同じMCPTTサービスに参加しているUE3，UE4，UE5に同一のグループIDが割り当てられていた場合、UE3，UE4，UE5の各々に送られるパケットが、UE3，UE4，UE5の全てに配信されることになる。
　通常、同報配信を用いて送られたパケットをUEが受信した場合、UE側で自機宛のパケットか否かを確認し、自機宛では無い場合にはそのパケットを破棄するという処理を行う。しかし、音声パケットに対して、例えば3GPPの音声コーデックである、AMR（Adaptive MultiRate）又はAMR-WB（AMR-WideBand）などが用いられる場合、通常、20msec毎にパケットが発生するため、UEがパケットの宛先を確認し、不要なパケットを破棄する頻度は高くなってしまう。また、同一のグループIDが割り当てられたリモートUEの数が大きいほど、リモートUEが確認・破棄するパケット数は増加し、リモートUEの処理負荷が増加する。また、リレーUEからリモートUEへ不要なパケットを多く送信することにより、無線リソースを無駄に消費することにもなる。
　本開示の一態様は、リレーUEの処理負荷の増加を抑えつつ、コア網のリソース及び無線リソースの消費を抑えることができる通信システム、リレー端末、リモート端末及び通信制御方法を提供することである。
　本開示の一態様に係る通信システムは、複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムであって、前記複数の端末は、リレー端末、及び、前記リレー端末を介して前記通信ノードと通信するリモート端末を含み、前記リモート端末は、当該リモート端末を前記通信ノードにユーザ登録するための第１のシグナリングを送信し、前記通信ノードは、前記第１のシグナリングを送信したリモート端末と、当該リモート端末が接続しているリレー端末との接続関係を検出し、前記発言権が与えられた端末から音声データを受信した場合、前記接続関係を有する前記リレー端末及び前記リモート端末のうち何れか１つの端末のみを前記音声データの送信先端末に決定し、前記送信先端末用のユニキャストベアラを用いて、前記音声データを送信し、前記リレー端末は、前記通信ノードから送信される前記音声データを、当該リレー端末に接続された全てのリモート端末へ送信する。
　本開示の一態様に係るリレー端末は、複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムにおけるリレー端末であって、前記音声データの送信先端末用のユニキャストベアラを用いて、前記通信ノードから送信される前記音声データを受信し、前記送信先端末は、前記発言権が与えられた端末から音声データを受信した場合に前記通信ノードにおいて決定され、前記リレー端末、及び、当該リレー端末に接続しているリモート端末のうち何れか１つの端末であり、前記リモート端末は前記リレー端末を介して前記通信ノードと通信する、受信部と、前記受信された前記音声データを、当該リレー端末に接続された全てのリモート端末へ送信する送信部と、を具備する構成を採る。
　本開示の一態様に係るリモート端末は、複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムにおける、リレー端末を介して前記通信ノードと通信するリモート端末であって、当該リモート端末を前記通信ノードにユーザ登録するための第１のシグナリングを送信する送信部と、前記リレー端末から送信される前記音声データを受信し、前記通信ノードから送信される前記音声データの送信先端末は、前記発言権が与えられた端末から音声データを受信した場合に前記通信ノードにおいて決定され、前記リレー端末、及び、当該リレー端末に接続しているリレー端末のうち何れか１つの端末であり、前記音声データは、前記送信先端末用のユニキャストベアラを用いて前記通信ノードから前記リレー端末へ送信される、受信部と、を具備する構成を採る。
　本開示の一態様に係る通信制御方法は、複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムにおける通信制御方法であって、前記複数の端末は、リレー端末、及び、前記リレー端末を介して前記通信ノードと通信するリモート端末を含み、前記リモート端末において、当該リモート端末を前記通信ノードにユーザ登録するための第１のシグナリングを送信し、前記通信ノードにおいて、前記第１のシグナリングを送信したリモート端末と、当該リモート端末が接続しているリレー端末との接続関係を検出し、前記発言権が与えられた端末から音声データを受信した場合、前記接続関係を有する前記リレー端末及び前記リモート端末のうち何れか１つの端末のみを前記音声データの送信先端末に決定し、前記送信先端末用のユニキャストベアラを用いて、前記音声データを送信し、前記リレー端末において、前記通信ノードから送信される前記音声データを、当該リレー端末に接続された全てのリモート端末へ送信する。
　なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　本開示の一態様によれば、リレーUEの処理負荷の増加を抑えつつ、コア網のリソース及び無線リソースの消費を抑えることができる。
　本開示の一態様における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
図１は、実施の形態１に係る通信システムの構成例を示す図である。 図２は、実施の形態１に係るMCPTTサーバの構成例を示す図である。 図３は、実施の形態１に係るリレーUEの構成例を示す図である。 図４は、実施の形態１に係るリモートUEの構成例を示す図である。 図５は、実施の形態１に係るリモートUEの登録処理時の動作をシーケンスチャートにより示す図である。 図６は、実施の形態１に係る音声通信時の動作をシーケンスチャート（ケース１）により示す図である。 図７は、実施の形態１に係る音声通信時の動作をシーケンスチャート（ケース２）により示す図である。 図８は、実施の形態１に係る音声通信時の動作をシーケンスチャート（ケース３）により示す図である。 図９は、実施の形態２に係る音声通信時の動作をシーケンスチャートにより示す図である。 図１０は、sidelink用MACサブヘッダの一例を示す図である。
　以下、本開示の各実施の形態について、図面を参照して詳細に説明する。なお、本開示の各実施の形態について、パケットの送信元・送信先を「ユニキャストIPアドレス」、「ブロードキャストIPアドレス/マルチキャストアドレス/ ProSe Group IP multicast address」などと特に明記していない場合には、ユニキャストIPアドレスを意味する。
　（実施の形態１）
　本実施の形態に係る通信システムは、図１に示す構成を採る。本実施の形態に係る通信システムは、少なくとも、MCPTTサーバ１００（通信ノードに相当）、リレーUE２００、リモートUE３００を備える。
　また、図１に示すPDN GW（Packet Data Network GateWay）４００、及び、Serving GW）は、非特許文献１０に記載されたノードであり、１対１配信の場合に音声データが通る経路である。また、eNBは、非特許文献１０などに記載されたノードであり、EPSにおける基地局である。
　図１では、eNBのカバレッジ内に存在するUE2がリレーUE２００に対応し、eNBのカバレッジ外に存在するUE3～UE5がリモートUE３００に対応する。
　また、前述した通り、図１に示すMCPTTサーバ１００は、MCPTTサービスに参加するUEの登録又はMCPTTセッションの制御を行うSIPサーバ、発言権制御を行う発言権制御サーバ、MCPTTサービスの参加者にデータを転送するメディア配布機能，非特許文献６に記載のProSe機能などを有すると仮定するが、実際には、これらのサーバ及び機能は、別々の名称を有するノード又は機能に分散して存在することも可能である。
　［各装置の構成］
　図２～図４は、それぞれ、図１に示すMCPTTサーバ１００、リレーUE２００、リモートUE３００の構成例を示すブロック図である。なお、MCPTTサーバ１００、リレーUE２００、リモートUE３００には、図２～図４に示す構成以外にも非特許文献１～１１に記載されているような機能を有するが、ここではその説明を省略する。
　図２に示すMCPTTサーバ１００は、受信部１０１、検出部１０２、格納部１０３、判断部１０４、パケット生成部１０５、及び送信部１０６を含む。
　MCPTTサーバ１００において、受信部１０１は、UEのSIPサーバへのユーザ登録時にUEから送信されるSIPシグナリングを受信し、MCPTTサービスの通信開始時にはUEから送信されるSIP INVITEシグナリングを受信する。また、受信部１０１は、音声通信時には、発言権（Floor grant）が与えられたUE（図１ではUE1）から送信された音声パケットを受信する。
　検出部１０２は、受信部１０１から受け取るユーザ登録時のSIPシグナリング、又は、既に登録されているUEの情報を用いて、MCPTTサービスにおいて同一グループサービスに参加しているリレーUE２００とリモートUE300との関係（接続関係）を検出する。格納部１０３は、検出部１０２で検出された上記関係を格納する。
　判断部１０４は、リモートUE３００からの通信開始時に、当該リモートUE３００用のベアラ確立の要否を判断する。また、判断部１０４は、MCPTTサービスにおける音声通信時に、格納部１０３に格納された情報（リレーUE２００とリモートUE300との関係）に基づいて、音声パケットの送信先UEを決定する。例えば、判断部１０４は、格納部１０３に格納された接続関係を有するリレーUE２００（図１ではUE2）及びリモートUE３００（図１ではUE3～UE5）のうち何れか１つのUEのみを音声データの送信先UEに決定する。
　パケット生成部１０５は、判断部１０４での判断結果（送信先UEの決定）に基づいてパケットを生成し、送信部１０６は、パケット生成部１０５で生成されたパケットを送信する。
　図３に示すリレーUE２００は、受信部２０１、パケット生成部２０２及び送信部２０３を含む。
　リレーUE２００において、受信部２０１は、リモートUE３００から送信される信号、又は、MCPTTサーバ１００から送信される信号を受信する。
　パケット生成部２０２は、受信部２０１から受け取る信号を用いてパケットを生成する。例えば、パケット生成部２０２は、MCPTTサーバ１００から送信される音声パケットを、リレーUE２００に接続された全てのリモートUE３００が受信できるように、当該音声パケットのヘッダ情報を変更して、リモートUE３００宛のパケットを生成してもよい。
　送信部２０３は、パケット生成部２０２で生成されたパケットを送信する。
　図４に示すリモートUE３００は、受信部３０１、判断部３０２、処理部３０３、及び送信部３０４を含む。
　リモートUE３００において、受信部３０１は、ユーザ登録時又は通信開始時のSIPシグナリング、又は、通信時の音声パケットを受信する。
　判断部３０２は、受信部３０１から受け取る音声パケットが自機宛てであるか否かを判断する。例えば、判断部３０２は、リレーUE２００から送信される音声パケットが自機から送信された音声パケットである場合には、音声パケットが自機宛てではないと判断する。
　処理部３０３は、自機宛ての音声パケットに対して処理（例えば、上位レイヤ処理部（図示せず）へのデータの受け渡しなど）を行う。一方、処理部３０３は、自機宛てではない音声パケット（例えば、自機が送信した音声パケット）を破棄する。
　送信部３０４は、ユーザ登録時又は通信開始時のSIPシグナリング、又は、発言権が付与された時の音声パケットを送信する。
　以上の構成を有する通信システムにおける動作について詳細に説明する。
　［リモートUEの登録処理］
　図２及び図５を用いて、リモートUE３００の登録処理（registration）時の各装置の動作について説明する。
　図５は、本実施の形態に係るリモートUE３００の登録処理時の動作の一例を示すシーケンスチャートである。なお、図５において、例えば、リモートUE３００は、図１に示すUE3～UE5であり、リレーUE２００は、図１に示すUE2である。
　図５において、リモートUE３００は、非特許文献９等に記載の通り、リレーUE２００に接続する（ステップ（以下、「ＳＴ」と表す）１０１）。リモートUE３００がリレーUE２００に接続すると、リモートUE３００には、リレーUE２００からIPアドレス（又はIPアドレスのプレフィックス）が割り当てられる。リモートUE３００は、割り当てられたIPアドレス（又は割り当てられたIPアドレスのプレフィックスから生成されたIPアドレス）を用いて、MCPTTサーバ１００に対してSIPシグナリングを用いた登録処理を行う（ＳＴ１０２）。
　登録処理を行う際、リモートUE３００は、接続しているリレーUE２００の情報を、登録処理のSIPシグナリングに明示的に含めてもよい。例えば、リモートUE３００は、接続しているリレーUE２００の情報を、SIPヘッダの一部、例えばviaヘッダなどに含めてもよく、SDP（Session Description Protocol）の中に含めてもよい。また、リモートUE３００は、前述のグループID又は、非特許文献６に記載された、グループIDと共に割り当てられるProSe Group IP multicast address、又はグループID及びProSe Group IP multicast addressの両方をSIPシグナリングに含める事により、リモートUE３００とリレーUE２００の関係をSIPサーバに伝えても良い。
　なお、登録処理のSIPシグナリングに対して、リレーUE２００によってパラメータの変更又は追加が行われてもよい。この場合、前述のようにリモートUE３００において、接続しているリレーUE２００の情報を、登録処理のSIPシグナリングに明示的に含めるのではなく、リレーUE２００が自機の情報を登録処理のSIPシグナリングに明示的に含める。例えば、リレーUE２００は、自機の情報を、SIPヘッダの一部、例えばviaヘッダなどに含めてもよく、SDPの中に含めてもよい。また、リレーUE２００は、前述のグループID又は、ProSe Group IP multicast address、又はグループID及びProSe Group IP multicast addressの両方をSIPシグナリングに追加する事により、リモートUE３００とリレーUE２００の関係をSIPサーバに伝えても良い。
　また、登録処理のSIPシグナリングは、リモートUE３００からMCPTTサーバ１００へ直接送信される場合に限定されない。例えば、リモートUE３００からリレーUE２００に登録処理のSIPシグナリングが送信され、リレーUE２００で一旦終端されてから、リレーUE２００がリモートUE用の登録処理のSIPシグナリングを新たに生成し、MCPTTサーバ１００に送信してもよい。この場合、前述のようにリモートUE３００が接続しているリレーUE２００の情報をリモートUE３００が生成する登録処理のSIPシグナリングに明示的に含めるのではなく、リレーUE２００が自機の情報を、リモートUE用の登録処理のSIPシグナリングに明示的に含めてもよい。例えば、リレーUE２００は、自機の情報を、SIPヘッダの一部、例えばviaヘッダなどに含めてもよく、SDPの中に含めてもよい。また、リレーUE２００は、前述のグループID又は、非特許文献６に記載されたProSe Group IP multicast address、又はグループID及びProSe Group IP multicast addressの両方をSIPシグナリングに追加する事により、リモートUE３００とリレーUE２００の関係をSIPサーバに伝えても良い。
　MCPTTサーバ１００において、受信部１０１が登録処理のSIPシグナリングを受け取ると、検出部１０２は、当該SIPシグナリングを送信したリモートUE３００と、そのリモートUE３００が接続しているリレーUE２００との関係（接続関係）を検出する（ＳＴ１０３）。リレーUE２００とリモートUE３００との関係の検出方法としては、例えば、SIPシグナリングに含まれるリレーUE２００の情報を用いてもよく、既に登録されている他のリモートUE３００とのIPアドレスの比較を用いてもよい。IPアドレスの比較を用いる場合、検出部１０２は、IPアドレス（IPv4の場合）又はIPアドレスのプリフィックス（IPv6の場合）を比較することにより、リレーUE２００とリモートUE３００との関係を検出してもよい。また、SIPヘッダのviaヘッダなどにリレーUE２００の情報が含まれている場合でも、MCPTTサーバ１００は、既に登録されているリレーUE２００の情報を照会し、viaヘッダに含まれている情報が本当にリレーUE２００の情報であるか否かを確認してもよい。またSIPシグナリングにグループID又は、ProSe Group IP multicast address、又はグループID及びProSe Group IP multicast addressの両方が含まれている場合には、MCPTTサーバ１００は、この情報を用いてリモートUE３００と、そのリモートUE３００が接続しているリレーUE２００との関係（接続関係）を検出しても良い。
　例えば、図１に示す例では、リモートUE３００であるUE3～UE5がユーザ登録を行った場合には、MCPTTサーバ１００の検出部１０２は、UE2がリレーUE２００であり、UE3，UE4，UE5がUE2に接続されたリモートUE３００であるという関係を検出する。
　MCPTTサーバ１００の格納部１０３は、ＳＴ１０３において検出部１０２が検出した、リレーUE２００とリモートUE３００との関係を示す情報を格納する（ＳＴ１０４）。格納部１０３は、SIPシグナリングにグループIDやProSe Group IP multicast addressが含まれている場合には、このグループIDやProSe Group IP multicast addressの情報も格納する。
　次いで、リモートUE３００は、非特許文献９等に記載の通り、MCPTTサービスの通信開始処理を行う（ＳＴ１０５）。例えば、リモートUE３００は、SIP INVITEシグナリングをMCPTTサーバ１００に送信する。
　この際、MCPTTサーバ１００の判断部１０４は、SIP INVITEシグナリングを送信したリモートUE３００用のベアラ（ユニキャストベアラ）を確立（又は更新）する必要があるか否かを判断する（ＳＴ１０６）。そして、判断部１０４は、ベアラ確立（又は更新）が必要な場合、非特許文献１０等に記載の通り、PCRF（Policy and Charging Rules Function。図示せず）などを通じて、PDN GW４００に対してリモートUE３００用のベアラ確立（又は更新）を要求する（ＳＴ１０７）。PDN GW４００は、リモートUE３００用のベアラ確立の要求を受け取ると、リモートUE３００用のEPCベアラを確立（更新）する（ＳＴ１０８）。
　例えば、判断部１０４は、格納部１０３に格納された情報（リレーUE２００とリモートUE３００との関係）に基づいて、既存ベアラの更新又はベアラの新規確立の際に必要となる情報（例えば、非特許文献１０等に記載のTFT（Traffic Flow Template）など）の設定の有無を判断する。判断部１０４は、この判断の際に他の情報、例えばMCPTTサーバ１００などにプリセットされたオペレータのポリシーなどの情報を用いてもよい。
　具体的には、判断部１０４は、リレーUE２００用の音声パケット用EPSベアラが既に存在している場合に、このEPSベアラにリモートUE３００用TFTを追加してもよい。この場合、判断部１０４は、上り（UEからPDN GW４００への方向）のTFT（UL TFT）を追加する。一方、判断部１０４は、下り（PDN GW４００からUEへの方向）に関しては、当該リモートUE３００宛てのパケットを送る場合にのみ下りのTFT（DL TFT）を追加し、当該リモートUE３００宛てのパケットを送らない場合には下りのTFTを追加しないと判断してもよい。また、判断部１０４は、下りのTFTを追加する際、TFTの送信先IPアドレスとして、リモートUE３００のユニキャストIPアドレスを用いても良いし、ProSe Group IP multicast addressを用いてもよい。
　また、判断部１０４は、リレーUE２００用の音声パケット用EPSベアラが既に存在している場合に、リモートUE３００用の音声パケット用EPSベアラを新たに確立してもよい。この場合、判断部１０４は、上りのTFTを設定する。一方、判断部１０４は、下りに関しては、当該リモートUE３００宛てのパケットを送る場合にのみ下りのTFTを設定し、当該リモートUE３００宛てのパケットを送らない場合には下りのTFTを設定しないと判断してもよい。また、判断部１０４は、下りのTFTを設定する際、TFTの送信先IPアドレスとして、リレーUE２００又はリモートUE３００のユニキャストIPアドレスを用いても良いし、ProSe Group IP multicast addressを用いてもよい。
　また、判断部１０４は、リレーUE２００が音声パケットをMBMSで受信しており、音声パケットのユニキャスト受信用（下り用）のEPSベアラが確立されていない場合（又はTFTが設定されていない場合）には、リレーUE２００用に下りのEPSベアラも同時に確立する（又はTFTを設定する）とともに、前述のように、リモートUE３００用TFTの追加を行うと判断してもよい。また、判断部１０４は、下りのTFTを設定する際、TFTの送信先IPアドレスとして、リレーUE２００又はリモートUE３００のユニキャストIPアドレスを用いても良いし、ProSe Group IP multicast addressを用いてもよい。
　また、判断部１０４は、リレーUE２００が音声パケットをMBMSで受信しており、音声パケットのユニキャスト受信用（下り用）のEPSベアラが確立されていない場合（又はTFTが設定されていない場合）には、リレーUE２００用に下りのEPSベアラを確立（又はTFTを設定）せずに、前述のように、リモートUE３００用ベアラを確立すると判断してもよい。また、判断部１０４は、下りのTFTを設定する際、TFTの送信先IPアドレスとして、リモートUE３００のユニキャストIPアドレスを用いても良いし、ProSe Group IP multicast addressを用いてもよい。
　なお、このEPSベアラ確立処理は、登録処理の後に行われてもよい。登録処理の後に行われるベアラ確立は、例えば、SIPシグナリング用ベアラ確立である。
　［音声パケット通信処理］
　次に、図５で説明した、登録処理、通信開始処理、ベアラ確立処理の完了後における音声パケットの通信処理について説明する。
　［ケース１：リレーUE２００及びリモートUE３００以外のUEからの音声パケット］
　まず、図２～図４、図６を用いて、図１のように、リレーUE２００（UE2）及びリモートUE３００（UE3～UE5）以外のUE（UE1）がMCPTTサーバ１００から発言権（Floor Grant）を与えられて、発言を開始した場合の処理について説明する。
　図６は、ケース１に係る音声パケット通信処理の動作の一例を示すシーケンスチャートである。
　図６において、MCPTTサーバ１００の受信部１０１は、上りの音声パケット（発言権を与えられたUE（図１ではUE1）から送信される音声パケット）を受け取る（ＳＴ２０１）。上りの音声パケットを受け取ると、MCPTTサーバ１００の判断部１０４は、格納部１０３に格納された情報（リレーUE２００とリモートUE３００との関係）に基づいて、この音声パケットの送信先としてどのUEに送信するかを判断する（ＳＴ２０２）。具体的には、判断部１０４は、格納部１０３に格納された上記関係におけるリレーUE２００及びリモートUE３００のうち何れか１つのUEのみを音声データの送信先UEに決定する。判断部１０４は、この判断の際、他の情報、例えばMCPTTサーバ１００などにプリセットされたオペレータのポリシーなどの情報なども一緒に用いてもよい。
　具体的には、判断部１０４は、図１に示すUE3～UE5のように、リレーUE２００（UE2）配下のリモートUE３００にはパケットを送信せず、代わりにリモートUE３００が接続しているリレーUE２００（UE2）にパケットを送信すると判断する。または、判断部１０４は、リレーUE２００に接続して同一のMCPTTサービスを受けているリモートUE３００のうちの１つのUEにパケットを送信すると判断してもよい。つまり、判断部１０４は、リレーUE２００及びリモートUE３００を含む複数のUEに対して、複数のUEの各々を送信先とせずに、リレーUE２００又は１つのリモートUE３００のみを送信先UEに決定する。
　また、判断部１０４は、リレーUE２００及びリモートUE３００、又はリモートUE３００のみに割り当てられている、ProSe Group IP multicast address宛にパケットを送信すると判断してもよい。また、ＳＴ２０２では、判断部１０４は、図５において確立されたEPSベアラの内容と合致するように、送信先UE（宛先）を判断する。例えば、判断部１０４は、図５のＳＴ１０６において設定した下りのTFTの送信先IPアドレス（例えば、リレーUE２００又はリモートUE３００のユニキャストIPアドレス、又は、ProSe Group IP multicast address）を用いて、パケットの送信先UEを決定する。
　MCPTTサーバ１００のパケット生成部１０５は、判断部１０４の判断結果に基づいて、下りパケットを生成する（ＳＴ２０３）。すなわち、パケット生成部１０５は、判断部１０４において決定された送信先UEを宛先とするヘッダ情報又はProSe Group IP multicast addressを宛先とするヘッダ情報を付加した音声パケットを生成する。生成されたパケット（下り）は、送信部１０６を介して送信先のUE（図６ではリレーUE２００。図１ではUE2）へ送信される（ＳＴ２０４）。送信されるパケットは、図５において確立又は更新されたEPSベアラ（ユニキャスト）を用いて送信される。
　リレーUE２００の受信部２０１は、MCPTTサーバ１００から送信された音声パケットを受信する（ＳＴ２０４）。または、リレーUE２００は、音声パケットの宛先がリモートUE３００宛ての場合でも、当該音声パケットをインターセプト（intercept）する。リレーUE２００は、受信した信号が音声パケットであるか否かに関して、EPSベアラのQCI（QoS Class Identifier。非特許文献１０などに記載）などで判断する。そして、リレーUE２００の受信部２０１は、受信した音声パケット又はインターセプトした音声パケットの宛先がリレーUE２００又はリモートUE３００のユニキャストIPアドレス宛であった場合、この音声を、パケット生成部２０２に出力する。また、受信部２０１は、受信した音声パケットの宛先がProSe Group IP multicast addressであった場合には音声パケットをパケット生成部２０２には出力せず、送信部２０３を介して送信する。
　パケット生成部２０２は、同一のグループIDが割り当てられた全てのリモートUE３００が音声パケットを自機（各リモートUE３００）宛として受信できるように、受信部２０１から受け取った音声パケットのヘッダ情報を変更して、リモートUE３００用のパケットを生成する（ＳＴ２０５）。
　例えば、パケット生成部２０２は、受け取った音声パケットのIPヘッダをブロードキャストアドレス又はマルチキャストアドレスに書き換える。なお、マルチキャストアドレスを用いる場合には、リモートUE３００が通信開始処理を完了するまでの間に、リレーUE２００とリモートUE３００との間でマルチキャストグループ参加に関する処理を行う必要がある。また、リレーUE２００は、音声パケットの送信に用いる送信先ポート番号に関しても、リモートUE３００との間で予め取り決めを行ってもよい。また、宛先アドレスとしてはProSe Group IP multicast addressを用いても良い。
　パケット生成部２０２で生成されたパケット（リモートUE３００宛てのパケット）は送信部２０３を介して送信される（ＳＴ２０６）。このように、リレーUE２００は、MCPTTサーバ１００から送信される音声パケットを、同一のグループIDが割り当てられた、当該リレーUE２００に接続された全てのリモートUE３００へ送信する。
　なお、リレーUE２００は、自機に接続されているリモートUE３００が１つである場合には、ブロードキャストアドレス又はマルチキャストアドレス、ProSe Group IP multicast addressなどを用いずに、リモートUE３００のユニキャストアドレス宛てにパケットを送信してもよい。
　リモートUE３００の受信部３０１は、リレーUE２００から送信されたパケットを受信する（ＳＴ２０６）。
　リモートUE３００の判断部３０２は、受信したパケット（リモートUE用）に対して処理を行うか否かを判断する（ＳＴ２０７）。具体的には、判断部３０２は、受信したパケットが自機宛の音声パケットであるか否かを、パケットのヘッダ情報より判断する。判断部３０２における音声パケットの判断には、非特許文献１３などに記載のパケット毎の優先度（PPP: Per Packet Priority）などを用いてもよい。また、判断部３０２は、現在自機に発言権が与えられていないこと、又は、他のUEに発言権が与えられていることを確認した場合、受け取った音声データを、自機が生成・送信した音声データではないと判断する。
　図６では、判断部３０２は、受信したパケットが自機宛ての音声パケットであり、自機に発言権が与えられていないので、受信したパケットに対して処理を行うと判断する。
　リモートUE３００の処理部３０３は、判断部３０２の判断に基づいてパケットを処理する。例えば、図６のように、判断部３０２の判断結果が、自機宛のパケットであり、かつ自機が生成・送信したパケットではないという判断である場合、処理部３０３は、受信したパケットを受け付け、データ（RTPパケット）を上位レイヤ（RTPレイヤ）に渡す処理などを行う（ＳＴ２０８）。
　［ケース２：リモートUE３００からの音声パケット］
　次に、図２～図４、図７を用いて、リモートUE３００（UE3～UE5）のうちいずれかのUEがMCPTTサーバ１００から発言権（Floor Grant）を得て、発言を開始した場合の処理について説明する。
　図７は、ケース２に係る音声パケット通信処理の動作の一例を示すシーケンスチャートである。なお、図７において、図６と同一の処理には同一の符号を付し、その説明を省略する。
　図７において、リモートUE３００は、音声パケットを生成し、リレーUE２００を介してMCPTTサーバ１００へ音声パケット（上り）を送信する（ＳＴ３０１）。
　この際、同一のグループIDが割り当てられた、発言権を得ていないリモートUE３００へ音声パケット（上り）が送られるが、発言権を得ていないリモートUE３００の判断部３０２は、宛先IPアドレスなどから自機宛ての音声パケットでは無い事を判断し、処理部３０３はパケットを破棄する。
　MCPTTサーバ１００は、リレーUE３００から送信された上りの音声パケットを受け取ると（ＳＴ３０１）、ケース１と同様、当該音声パケットの送信先UE（リレーUE２００又は１つのリモートUE３００、又はProSe Group IP multicast addressを宛先とするUE群）を決定し（ＳＴ２０２）、下りのパケットを生成し（ＳＴ２０３）、パケット（下り）を送信する（ＳＴ２０４）。
　なお、MCPTTサーバ１００の判断部１０４は、格納部１０３の情報に基づいて、パケットを送信してきたUEがリモートUE３００であり、当該リモートUE３００がリレーUE２００に接続された唯一のリモートUE３００である場合、かつ、リレーUE２００がこのパケットを受け取る必要が無い場合（例えば、リレーUE２００がMBMSで音声パケットを受け取っている場合など）には、リレーUE２００にパケットを送信しないと判断してもよい。
　また、ケース１と同様、リレーUE２００は、MCPTTサーバ１００から送信された音声パケットを受信し（ＳＴ２０４）、音声パケットを自機配下のリモートUE３００が受信できるように音声パケットのヘッダ情報を変更し（ＳＴ２０５）、生成したリモートUE用パケットを送信する（ＳＴ２０６）。又は、受信した音声パケットの宛先がProSe Group IP multicast addressであった場合は、リレーUE２００の受信部２０１は、音声パケットをパケット生成部２０２には出力せず、送信部２０３を介して送信する。
　リモートUE３００の判断部３０２は、受信したパケット（リモートUE用）に対して処理を行うか否かを判断する（ＳＴ２０７）。具体的には、判断部３０２は、受信したパケットが自機宛の音声パケットであるか否かを、パケットのヘッダ情報より判断する。また、判断部３０２は、現在自機に発言権が与えられていないこと、又は、他のUEに発言権が与えられていることを確認した場合、受け取った音声データを自機が生成・送信した音声データではないと判断する。
　図７では、判断部３０２は、自機宛てのパケットであるが、自機に発言権が与えられているので、受信したパケットが自機で生成・送信した音声パケットであると判断する。つまり、判断部３０２は、受信したパケットに対して処理を行わずに破棄すると判断する。
　リモートUE３００の処理部３０３は、判断部３０２の判断に基づいてパケットを処理する。図７では、処理部３０３は、受信したパケットが自機で生成・送信した音声パケットであると判断されたので、当該音声パケットを破棄する処理を行う（ＳＴ３０２）。
　［ケース３：リモートUE３００からの音声パケット］
　次に、図２～図４、図８を用いて、リモートUE３００（UE3～UE5）のうちいずれかのUEがMCPTTサーバ１００から発言権（Floor Grant）を得て、発言を開始した場合のケース２とは別の処理について説明する。
　図８は、ケース３に係る音声パケット通信処理の動作の一例を示すシーケンスチャートである。
　図８において、リモートUE３００は、ブロードキャストアドレス、マルチキャストアドレス、又はProSe Group IP multicast addressなどを宛先とした音声パケットを生成し、同一グループIDを持つリレーUE２００及びリモートUE３００に送信する（ＳＴ４０１）。
　ここで、発言権を得ていないリモートUE３００の判断部３０２は、自機宛ての音声パケットである事を判断し、処理部３０３は、受信したパケットを受け付け、データ（RTPパケット）を上位レイヤ（RTPレイヤ）に渡す処理などを行う。
　リレーUE２００の受信部２０１は、リモートUE３００から送信された音声パケットを受信する（ＳＴ４０１）。リレーUE２００は、受信した信号が音声パケットであるか否かに関して、非特許文献１３に記載のPer Packet Priorityなどで判断する。そして、リレーUE２００の受信部２０１は、受信した音声パケットを、パケット生成部２０２に出力する。
　パケット生成部２０２は、受信部２０１から受け取った音声パケットのヘッダの宛先をMCPTTサーバ１００に変更するなどの必要な処理を行い、リモートUE３００を送信元、MCPTTサーバ１００を送信先とするパケットを生成する（ＳＴ４０２）。
　パケット生成部２０２で生成されたパケット（MCPTTサーバ１００宛てのパケット）は送信部２０３を介して送信される（ＳＴ４０３）。このように、リレーUE２００は、リモートUE３００から送信される音声パケットを、MCPTTサーバ１００へ送信する。
　MCPTTサーバ１００がリレーUE２００から送信された上りの音声パケットを受け取ると（ＳＴ４０３）、MCPTTサーバ１００の判断部１０４は、格納部１０３の情報に基づいて、パケットを送信してきたUEがリモートUE３００であり、同一グループIDを持つUE（リレーUE２００，リモートUE３００）が既にこの音声パケットを受け取っていると判断し、リレーUE２００又はリモートUE３００にパケットを送信しないと判断してもよい（ＳＴ４０４）。
　以上、本実施の形態に係る動作について説明した。
　このように、本実施の形態に係る通信システムでは、MCPTTサーバ１００は、MCPTTのグループサービスに参加するUEにおけるリレーUE２００とリモートUE３００との関係を保持する。そして、MCPTTサーバ１００は、音声通信時には、リレーUE２００（又はリモートUE３００の何れか１つのUE）、又はProSe Group IP multicast addressを宛先とするUE群に対してのみ音声パケットを送信する。そして、リレーUE２００は、受け取った音声パケットを、自機配下のリモートUE３００へ送信する。
　これにより、EPS内では、MCPTTのグループサービスに参加するリモートUE３００が存在する場合でも、１つのUE（リレーUE２００）向けのパケットのみが送信されるので、EPS（コア網）でのリソースが無駄に消費されることを防ぐことができる。
　また、リレーUE２００は、MCPTTサーバ１００が１つのUE向けに送信した音声パケットを、自機配下の全てのリモートUE３００（同一のグループIDが割り当てられたUE）へそれぞれ配信する。これにより、リレーUE２００とリモートUE３００との間のProSe通信でもUE毎のパケットが全てのUEに無駄に配信されることなく、無線リソースが無駄に消費されることを防ぐことができる。
　また、リレーUE２００は、MCPTTサーバ１００から送信される音声パケットを、同一のグループIDが割り当てられた全てのリモートUE３００へ配信すればよく、リモートUE３００毎のグループIDの管理する必要が無いので、リレーUE２００の処理負荷の増加を抑えることができる。
　以上より、本実施の形態によれば、MCPTTサービスにおいて、リレーUE２００の処理負荷の増加を抑えつつ、コア網のリソース及び無線リソースの消費を抑えることができる。
　（実施の形態２）
　本実施の形態では、リレーUE２００と個々のリモートUE３００がグループIDを用いずに直接(one to one)通信する方法について説明する。
　MCPTTサーバ１００内のProSe機能は、リレーUE２００及びリモートUE３００に対して、グループIDに加え、UE-to-Network relayの際の直接通信に必要なLayer2 ID（以下直接通信IDと言う）を付与する。この直接通信IDは、リレーUE２００とリモートUE３００がリレーUE及びリモートUEの関係になった際に配布されても良いし、リレーUE及びリモートUEの関係になる前に予め配布されていても良い。また、この直接通信IDは、同じMCPTTサービスに参加する全UEに重複せずに与えられるIDであっても良いし、リレーUE及び同じリレーUEに繋がるリモートUE間に重複せずに与えられるものであっても良い。また、直接通信IDは、MCPTTサーバ１００内のProSe機能ではなく、リレーUEがリモートUEに対し付与しても良い。また、この直接通信IDは、非特許文献６に記載のProSe UE IDであっても良い。
　［リモートUEの登録処理］
　本実施の形態におけるリモートUEの登録処理に関し、リモートUE３００、リレーUE２００及びMCPTTサーバ１００に新たな機能追加する必要は無い。登録処理、通信開始処理、ベアラ確立処理などは、リレーUE２００とリモートUE３００の関係を意識せずに処理が行われる。
　［音声パケット通信処理］
　図１～図４及び図９，図１０を用いて本実施の形態の音声パケット通信処理を説明する。
　図９は、本実施の形態に係る音声パケット通信処理の動作の一例を示すシーケンスチャートである。
　図９において、MCPTTサーバ１００の受信部１０１は、上りの音声パケット（発言権を与えられたUE（図１ではUE1）から送信される音声パケット）を受け取る（ＳＴ５０１）。上りの音声パケットを受け取ると、MCPTTサーバ１００の判断部１０４は、上りの音声パケットを送信したUE以外で、EPSベアラで下りの音声パケットを受け取る全てのUEに対し、音声パケットを送るよう判断する（ＳＴ５０２）。なお、この判断は上りの音声パケットの送信元がリモートUE３００であっても同じである。MCPTTサーバ１００のパケット生成部１０５は、判断部１０４の判断結果に基づいて、下りパケットを生成する（ＳＴ５０３）。生成されたパケット（下り）は、送信部１０６を介して送信先のUEへ送信される（ＳＴ５０４）。
　リレーUE２００の受信部２０１は、MCPTTサーバ１００から送信された音声パケットを受信する（ＳＴ５０４）。
　リレーUE２００のパケット生成部２０２は、直接通信IDを用いてリモートUE３００向けのパケットを生成する（ＳＴ５０５）。具体的には、パケット生成部２０２は、リモートUE３００のIPアドレスと、リモートUE３００の直接通信IDが合致するように、非特許文献１１及び非特許文献７に記載の通りLayer2の処理を行う。なお、リレーUE２００及びリモートUE３００間の直接通信IDの交換(exchange)は、リモートUE３００がリレーUE２００を発見(Discovery)し、接続する際に行われても良いし、前述のように、リモートUE３００がリレーUE２００に接続した際に、リレーUE２００がリモートUE３００に直接通信IDを割り当てても良い。
　図１０は非特許文献７に記載のsidelink用MAC(Medium Access Control)サブヘッダを示す。パケット生成部２０２は、図１０に示すDST欄に、グループIDの代わりにリモートUE３００のIPアドレスと対応付けられている直接通信ID又はその一部を入力する。リレーUE２００は、直接通信ID（又はその一部）の大きさが図１０のように16ビットに合わないようであれば、DST欄の大きさを変更してもよい。また、リレーUE２００は、通常のグループIDを使った通信と区別するために、図１０に示すV欄(MAC PDU format version number)の値を直接通信用に設定しても良い。また、リレーUE２００は、SRC欄に関しても、リレーUE２００の直接通信IDを用いても良いし、直接通信IDの大きさが24ビットに合わないようであれば、SRC欄の大きさを変更しても良い。また、本実施の形態では、既存のsidelink用MACサブヘッダを変更するのではなく、直接通信用に全く新しいMACサブヘッダを定義しても良い。
　リレーUE２００の送信部２０３から送信されたパケットは、リモートUE３００の受信部３０１によって受信される（ＳＴ５０６）。リモートUE３００のMACサブレイヤは、宛先の直接通信IDにより自機宛である事を確認し、受信処理を行う（ＳＴ５０７）。
　上述した直接通信処理は、リモートUE３００からリレーUE２００にパケット送信を行う場合も同様である。
　以上、本実施の形態に係る動作について説明した。
　これにより、リレーUE２００及びリモートUE３００のLayer 2（非特許文献１１記載）のみを変更する事により、リレーUE２００、リモートUE３００、MCPTTサーバ１００への変更を抑えつつ、リレーUE２００とリモートUE３００との間の無線リソースの無駄な消費を抑える事ができる。
　以上、本開示各実施の形態について説明した。
　なお、上記実施の形態で説明したリモートUE３００において、自機が発信したパケットを破棄するメカニズム（例えば、図７を参照）は、ブロードキャスト又はマルチキャストを用いたグループ通信で適用してもよい。
　また、上記実施の形態では、音声パケットの通信を行う通信システムについて説明したが、通信システムは、音声パケット以外の他のパケット、例えば発言権制御（Floor Control）のパケットに対して適用してもよい。また、音声以外のメディア（映像など）のパケットに適用してもよい。
　また、上記実施の形態ではMCPTTを例として説明したが、同様のアーキテクチャを用いる他のサービスに対して適用しても良い。
　また、本開示の一態様は、上記各実施の形態に限定されず、種々変更して実施することが可能である。
　また、上記各実施の形態では、本開示の一態様をハードウェアで構成する場合を例にとって説明したが、本開示はハードウェアとの連携においてソフトウェアでも実現することも可能である。
　また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には、入力端子及び出力端子を有する集積回路であるＬＳＩとして実現される。集積回路は、上記実施の形態の説明に用いた各機能ブロックを制御し、入力端子と出力端子を備えてもよい。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
　また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）または、ＬＳＩ内部の回路セルの接続若しくは設定を再構成可能なリコンフィギュラブル／プロセッサを利用してもよい。
　さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　本開示の一態様は、MCPTTのサービスを提供する通信システム及び通信システムを利用するユーザ端末に有用である。
　１００　MCPTTサーバ
　１０１，２０１，３０１　受信部
　１０２　検出部
　１０３　格納部
　１０４，３０２　判断部
　１０５，２０２　パケット生成部
　１０６，２０３，３０４　送信部
　２００　リレーUE
　３００　リモートUE
　３０３　処理部
　４００　PDN GW

Claims (12)

  1. 　複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムであって、
    　前記複数の端末は、リレー端末、及び、前記リレー端末を介して前記通信ノードと通信するリモート端末を含み、
    　前記リモート端末は、
    　　当該リモート端末を前記通信ノードにユーザ登録するための第１のシグナリングを送信し、
    　前記通信ノードは、
    　　前記第１のシグナリングを送信したリモート端末と、当該リモート端末が接続しているリレー端末との接続関係を検出し、
    　　前記発言権が与えられた端末から音声データを受信した場合、前記接続関係を有する前記リレー端末及び前記リモート端末のうち何れか１つの端末のみを前記音声データの送信先端末に決定し、
    　　前記送信先端末用のユニキャストベアラを用いて、前記音声データを送信し、
    　前記リレー端末は、
    　　前記通信ノードから送信される前記音声データを、当該リレー端末に接続された全てのリモート端末へ送信する、
    　通信システム。
  2. 　前記リモート端末が送信する前記第１のシグナリングには、当該リモート端末が接続するリレー端末の情報が含まれ、
    　前記通信ノードは、前記リレー端末の情報を用いて前記接続関係を検出する、
    　請求項１に記載の通信システム。
  3. 　前記リレー端末は、前記リモート端末から送信される前記第１のシグナリングに、当該リレー端末の情報を含め、
    　前記通信ノードは、前記リレー端末の情報を用いて前記接続関係を検出する、
    　請求項１に記載の通信システム。
  4. 　前記第１のシグナリングは、ＳＩＰ（Session Initiation Protocol）シグナリングであって、
    　前記リレー端末の情報は、viaヘッダ又はＳＤＰ（Session Description Protocol）の中に含まれる、
    　請求項２又は３に記載の通信システム。
  5. 　前記リモート端末は、前記通信ノードへの登録後に、通信を開始するための第２のシグナリングを送信し、
    　前記通信ノードは、前記接続関係に基づいて、前記第２のシグナリングを送信した前記リモート端末へ前記音声データを送信するためのユニキャストベアラを確立する必要があるか否かを判断し、確立が必要と判断した場合、前記ユニキャストベアラの確立を要求する、
    　請求項１に記載の通信システム。
  6. 　前記送信先端末は、前記リレー端末である、
    　請求項１に記載の通信システム。
  7. 　前記送信先端末は、１つのリモート端末であって、
    　前記リレー端末は、前記１つのリモート端末宛ての前記音声データをインターセプトし、前記インターセプトした音声データを前記全てのリモート端末へ送信する、
    　請求項１に記載の通信システム。
  8. 　前記リレー端末は、前記音声データを前記全てのリモート端末が受信できるように、当該音声データのヘッダ情報を変更する、
    　請求項１に記載の通信システム。
  9. 　前記リモート端末は、前記リレー端末から送信される前記音声データが自機から送信されたデータである場合、当該音声データを破棄する、
    　請求項１に記載の通信システム。
  10. 　複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムにおけるリレー端末であって、
    　前記音声データの送信先端末用のユニキャストベアラを用いて、前記通信ノードから送信される前記音声データを受信し、前記送信先端末は、前記発言権が与えられた端末から音声データを受信した場合に前記通信ノードにおいて決定され、前記リレー端末、及び、当該リレー端末に接続しているリモート端末のうち何れか１つの端末であり、前記リモート端末は前記リレー端末を介して前記通信ノードと通信する、受信部と、
    　前記受信された前記音声データを、当該リレー端末に接続された全てのリモート端末へ送信する送信部と、
    　を具備するリレー端末。
  11. 　複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムにおける、リレー端末を介して前記通信ノードと通信するリモート端末であって、
    　当該リモート端末を前記通信ノードにユーザ登録するための第１のシグナリングを送信する送信部と、
    　前記リレー端末から送信される前記音声データを受信し、前記通信ノードから送信される前記音声データの送信先端末は、前記発言権が与えられた端末から音声データを受信した場合に前記通信ノードにおいて決定され、前記リレー端末、及び、当該リレー端末に接続しているリレー端末のうち何れか１つの端末であり、前記音声データは、前記送信先端末用のユニキャストベアラを用いて前記通信ノードから前記リレー端末へ送信される、受信部と、
    　を具備するリモート端末。
  12. 　複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムにおける通信制御方法であって、
    　前記複数の端末は、リレー端末、及び、前記リレー端末を介して前記通信ノードと通信するリモート端末を含み、
    　前記リモート端末において、
    　　当該リモート端末を前記通信ノードにユーザ登録するための第１のシグナリングを送信し、
    　前記通信ノードにおいて、
    　　前記第１のシグナリングを送信したリモート端末と、当該リモート端末が接続しているリレー端末との接続関係を検出し、
    　　前記発言権が与えられた端末から音声データを受信した場合、前記接続関係を有する前記リレー端末及び前記リモート端末のうち何れか１つの端末のみを前記音声データの送信先端末に決定し、
    　　前記送信先端末用のユニキャストベアラを用いて、前記音声データを送信し、
    　前記リレー端末において、
    　　前記通信ノードから送信される前記音声データを、当該リレー端末に接続された全てのリモート端末へ送信する、
    　通信制御方法。
PCT/JP2016/003853 2015-09-24 2016-08-24 通信システム、リレー端末、リモート端末及び通信制御方法 WO2017051503A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2017541224A JPWO2017051503A1 (ja) 2015-09-24 2016-08-24 通信システム、リレー端末、リモート端末及び通信制御方法
US15/916,138 US10420057B2 (en) 2015-09-24 2018-03-08 Communication system, relay terminal, remote terminal, and communication control method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2015187150 2015-09-24
JP2015-187150 2015-09-24

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/916,138 Continuation US10420057B2 (en) 2015-09-24 2018-03-08 Communication system, relay terminal, remote terminal, and communication control method

Publications (1)

Publication Number Publication Date
WO2017051503A1 true WO2017051503A1 (ja) 2017-03-30

Family

ID=58385872

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/003853 WO2017051503A1 (ja) 2015-09-24 2016-08-24 通信システム、リレー端末、リモート端末及び通信制御方法

Country Status (3)

Country Link
US (1) US10420057B2 (ja)
JP (1) JPWO2017051503A1 (ja)
WO (1) WO2017051503A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170374633A1 (en) * 2015-03-12 2017-12-28 Huawei Technologies Co., Ltd. Real-time transport protocol rtp packet transmission method and apparatus
JP2022095930A (ja) * 2018-12-24 2022-06-28 華碩電腦股▲ふん▼有限公司 無線通信システムにおいて１対１のサイドリンク通信を支援するための方法および装置
WO2023189019A1 (ja) * 2022-03-28 2023-10-05 株式会社Ｊｖｃケンウッド 通信端末、通信管理サーバ及び通信システム

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107211271B (zh) * 2015-12-31 2020-02-14 华为技术有限公司 用户设备接入网络的方法、核心网实体、基站及第一ue
US10736070B2 (en) * 2017-07-26 2020-08-04 Blackberry Limited Method and system for use of a relay user equipment in an internet protocol multimedia subsystem
WO2019209778A1 (en) * 2018-04-23 2019-10-31 Kyocera Corporation Broadcast transmission by relay node
WO2022056658A1 (en) * 2020-09-15 2022-03-24 Qualcomm Incorporated Device-to-device sidelink voice data reliability enhancement
WO2022165787A1 (zh) * 2021-02-07 2022-08-11 Oppo广东移动通信有限公司 参数配置方法、装置、设备及存储介质
CN115589584A (zh) * 2021-07-05 2023-01-10 维沃移动通信有限公司 多路径通信方法和设备
WO2023014158A1 (en) * 2021-08-05 2023-02-09 Samsung Electronics Co., Ltd. A method and system for handling call setup parameters for remotely initiated call
CN116418736A (zh) * 2021-12-29 2023-07-11 华为技术有限公司 一种多路径通信方法及设备
FR3139694A1 (fr) * 2022-09-08 2024-03-15 Thales Système et procédé de communication sans fil critique par redondance

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS60236561A (ja) * 1984-05-10 1985-11-25 Fujitsu Ltd 会議通信方式

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US150483A (en) * 1874-05-05 Improvement in shirt-bosoms
EP3206457A4 (en) * 2014-10-07 2018-06-27 Nec Corporation Relay wireless terminal, core network device, and methods for both
WO2016163430A1 (ja) * 2015-04-10 2016-10-13 京セラ株式会社 無線端末及び制御方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS60236561A (ja) * 1984-05-10 1985-11-25 Fujitsu Ltd 会議通信方式

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
3GPP: "SA6, Presentation of TR 23.779 v2.0.0: Study on application architecture to support Mission Critical Push To Talk over LTE (MCPTT) services (Release 13", 3GPP TSG-SA#69, SP-150483, pages 79 - 89, XP051012145 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170374633A1 (en) * 2015-03-12 2017-12-28 Huawei Technologies Co., Ltd. Real-time transport protocol rtp packet transmission method and apparatus
US10448348B2 (en) * 2015-03-12 2019-10-15 Huawei Technologies Co., Ltd. Real-time transport protocol RTP packet transmission method and apparatus
JP2022095930A (ja) * 2018-12-24 2022-06-28 華碩電腦股▲ふん▼有限公司 無線通信システムにおいて１対１のサイドリンク通信を支援するための方法および装置
JP7503093B2 (ja) 2018-12-24 2024-06-19 華碩電腦股▲ふん▼有限公司 無線通信システムにおいて１対１のサイドリンク通信を支援するための方法および装置
WO2023189019A1 (ja) * 2022-03-28 2023-10-05 株式会社Ｊｖｃケンウッド 通信端末、通信管理サーバ及び通信システム

Also Published As

Publication number Publication date
US20180199301A1 (en) 2018-07-12
JPWO2017051503A1 (ja) 2018-07-12
US10420057B2 (en) 2019-09-17

Similar Documents

Publication Publication Date Title
WO2017051503A1 (ja) 通信システム、リレー端末、リモート端末及び通信制御方法
CN104769910B (zh) 在通信网络中指派地址
EP2074842B1 (en) Efficient mbms backbone distribution using one tunnel approach
KR100951026B1 (ko) 무선 원격통신 장치들 간의 그룹 통신들에 있어서 ｖｏｉｐ데이터 패킷들을 분배하기 위한 시스템 및 방법
WO2019080690A1 (zh) 一种通信系统、通信方法及其装置
JP4977721B2 (ja) ダウンリンクマルチキャストサービス（例えばｍｂｍｓ）を用いることによる双方向サービス（ｉｍｓ，例えばｐｏｃ，会議）のサービスデータの提供
JP4945577B2 (ja) ダウンリンクマルチキャストサービス（例えば、ｍｂｍｓ）の利用による双方向サービス（ｉｍｓ、例えば、ｐｏｃ、会議）のサービスデータの提供
KR101785185B1 (ko) 셀룰러 네트워크 멀티캐스트 전송에서의 멀티캐스트 그룹 재사용
US20070019645A1 (en) Method and system for multicasting data in a communication network
CN107211483B (zh) 一种数据通信方法及终端
WO2014000591A1 (zh) 一种路由功能启动及数据传输的方法、设备和系统
KR100942799B1 (ko) 트래픽 처리시스템 및 그 방법
WO2009076864A1 (zh) 点到多点gtp隧道的建立方法、网络设备
EP1380182A1 (en) One-to-one communication, where the system having different control plane and user plane logical entities
US8270407B2 (en) Managing data streams in communication system
JP5184208B2 (ja) モバイル通信においてブロードキャスト／マルチキャストサービスを提供する設備と方法
US10560878B2 (en) Communication system, terminal, and communication control method
WO2016115670A1 (zh) 一种数据流传输方法、设备及系统
CN110809242B (zh) 一种dect网络集群下的媒体交互方法
WO2017017888A1 (ja) 通信システム、通信ノード、端末及び通信制御方法
KR20100069442A (ko) 패킷기반 이동통신 시스템에서 ｍｂｍｓ 데이터 전송을 위한 베어러 설정 방법과 ｍｂｍｓ 코어 네트워크 장치 및 무선기지국
KR20040048494A (ko) 무선 랜과 범용 이동통신 시스템 망간 연동 방안

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: 16848294

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017541224

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16848294

Country of ref document: EP

Kind code of ref document: A1