WO2018029939A1 - 端末、基地局及び通信方法 - Google Patents

端末、基地局及び通信方法 Download PDF

Info

Publication number
WO2018029939A1
WO2018029939A1 PCT/JP2017/019456 JP2017019456W WO2018029939A1 WO 2018029939 A1 WO2018029939 A1 WO 2018029939A1 JP 2017019456 W JP2017019456 W JP 2017019456W WO 2018029939 A1 WO2018029939 A1 WO 2018029939A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
terminal
ecn
correspondence information
compression mode
Prior art date
Application number
PCT/JP2017/019456
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 JP2018533431A priority Critical patent/JP6847115B2/ja
Publication of WO2018029939A1 publication Critical patent/WO2018029939A1/ja
Priority to US16/224,492 priority patent/US10716029B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M11/00—Telephonic communication systems specially adapted for combination with other electrical systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/16—Performing reselection for specific purposes
    • H04W36/22—Performing reselection for specific purposes for handling the traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/24—Reselection being triggered by specific parameters
    • H04W36/26—Reselection being triggered by specific parameters by agreed or negotiated communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/34—Reselection control
    • H04W36/38—Reselection control by fixed network equipment
    • H04W36/385—Reselection control by fixed network equipment of the core network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H04W8/245—Transfer of terminal data from a network towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/35—Flow control; Congestion control by embedding flow control information in regular packets, e.g. piggybacking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0284—Traffic management, e.g. flow control or congestion control detecting congestion or overload during communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point

Definitions

  • the present disclosure relates to a terminal, a base station, and a communication method.
  • RoHC Robust Header Compression
  • IP Internet Protocol
  • UDP User Datagram Protocol
  • RTP Real-time Transport Protocol
  • FIG. 1 shows a state transition diagram of RoHC.
  • RoHC states There are three RoHC states: an IR (Initialization and Refresh) state, an FO (First Order) state, and an SO (Second Order) state.
  • the IR state is the lowest compression, and the higher the compression is as the FO state and the SO state are reached.
  • FIG. 2 shows (A) IPv4 (IP version 4) header, (B) IPv6 (IP version 6) header, (C) UDP header, and (D) RTP header static fields (Static part). And the classification of the dynamic field (Dynamic part).
  • the terminal In the IR state, almost no compression is performed, and the terminal transmits all static information and dynamic information. In the FO state, the terminal compresses the static field and transmits the dynamic field without compression. In the SO state, the terminal determines a field that can hardly be changed in the corresponding communication even in a dynamic field, or field information that can be reproduced from information of another field, and transmits only a minimum field in a simplified form.
  • the start of communication it starts from the IR state and transitions to the high compression mode from the FO state or the SO state according to the judgment on the transmitting side or the feedback information from the receiving side.
  • the SO state is changed to the FO state, IR state, or FO state. Transition to the IR state and the low compression mode.
  • the low compression mode includes IR and IR-DYN
  • the high compression mode includes UO-0, R-0, R-0-CRC, R-1, and R-1-ID.
  • the compression mode (sometimes referred to as high compression mode) is used in, for example, VoLTE (Voice over LTE).
  • VoLTE Voice over LTE
  • the IP header, UDP header, and RTP header are compressed to a maximum of 3 bytes by transmitting only the RTP sequence number and UDP checksum (in the case of IPv6) in a voiced section (see Non-Patent Document 3, for example).
  • IP header information it is not assumed that IP header information is included. Therefore, in VoLTE, the compression mode when there is a change in the IP header information is implementation-dependent.
  • ECN Exlicit Congestion Notification
  • 3GPP 3GPP
  • ECN Exlicit Congestion Notification
  • Non-Patent Document 4 a technology for notifying a terminal of communication channel congestion during real-time communication such as VoLTE and prompting a change in the bit rate of the codec (for example, Non-Patent Document 4).
  • Non-patent Document 5 ECN is standardized in Non-Patent Document 6.
  • ECN uses the least significant 2 bits (hereinafter referred to as ECN bit) of IPv4 ToS (Type of Service) field or IPv6 Traffic Class field when notifying congestion using an IP header.
  • ECN bit the least significant 2 bits
  • terminals that communicate with each other indicate whether or not a terminal supports ECN regardless of whether or not a connection destination base station supports ECN.
  • Protocol Exchange between terminals just before communication using offer and SDP answer, and negotiate whether ECN is used by both terminals.
  • FIG. 3 shows an example of an SDP offer and an SDP answer regarding ECN negotiation described in Non-Patent Document 5.
  • one terminal sets the ECN bit of the IP header to “01” or “10”, notifies the base station that the ECN is supported, and supports the ECN.
  • the base station sets the ECN bit of the IP header to “11” and notifies the other terminal that congestion has occurred.
  • the terminal notified of the occurrence of congestion from the base station transmits request signaling to the communication counterpart terminal so as to lower the bit rate of the codec.
  • FIG. 4A and 4B show examples of congestion notification and bit rate change request using ECN.
  • FIG. 4A shows an example in which congestion in the direction of the core network 412 is detected by the base station 404 in IP packet transmission from the terminal 400 to the terminal 402
  • FIG. 4B shows in IP packet transmission from the terminal 400 to the terminal 402.
  • An example in which congestion in the direction of the radio access network 410 is detected by the base station 406 is shown.
  • the terminal 400 sets the ECN bit of the IP header to “10” and transmits it to the terminal 402 to indicate that it corresponds to ECN.
  • the base station 404 existing on the communication path from the terminal 400 to the terminal 402 detects congestion on the core network 412 side or uplink congestion on the radio access network 408 side, and sets the ECN bit of the IP header to “11”.
  • the terminal 402 transmits a bit rate change request to the terminal 400 for requesting to lower the bit rate.
  • the terminal 400 sets the ECN bit of the IP header to “10” and transmits it to the terminal 402 to indicate that it corresponds to ECN.
  • the base station 406 present on the communication path from the terminal 400 to the terminal 402 detects the downlink congestion on the radio access network 410 side, changes the ECN bit of the IP header to “11”, and then returns to the terminal 402. Send.
  • the terminal 402 detects that the ECN bit of the IP header is “11”
  • the terminal 402 transmits a bit rate change request to the terminal 400 for requesting a reduction in the bit rate. This process is the same for IP packet transmission from the terminal 402 to the terminal 400.
  • E-UTRA Evolved Universal Terrestrial Radio Access
  • PDCP Packet Data Convergence Protocol
  • ROHC ROI: Framework, and four profiles: RTP, UDP, ESP, and uncompressed, C.
  • VoLTE high compression mode includes an IP header.
  • ECN notifies congestion using an IP header. Therefore, it is difficult to apply the high compression mode in an environment that supports ECN.
  • a non-limiting example of the present disclosure is to provide a terminal, a base station, and a communication method that can appropriately apply the high compression mode in an environment that supports ECN.
  • a terminal includes: an acquisition unit that acquires first application correspondence information indicating an application to which a base station that exists on a communication path with a communication partner terminal corresponds; A negotiation unit that negotiates use of an application that matches the application indicated in the first application correspondence information with the communication partner terminal, and a compression mode determination unit that determines a compression mode based on the negotiation result of the application. It has.
  • the base station includes a notification unit that notifies the terminal of first application correspondence information indicating an application supported by the own device, and communication of the terminal based on the first application correspondence information in the terminal
  • An application information acquisition unit that acquires application information negotiated with a partner terminal, and a compression mode determination unit that determines a compression mode based on the acquired negotiated application information.
  • a communication method obtains first application correspondence information indicating an application to which a base station existing on a communication path between a terminal and a communication partner terminal corresponds, and among the applications to which the terminal corresponds.
  • the use of an application that matches the application indicated in the first application correspondence information is negotiated with the communication partner terminal, and the compression mode is determined based on the negotiation result of the application.
  • a communication method notifies first application correspondence information indicating an application supported by a base station to a terminal, and communicates with a communication partner terminal of the terminal based on the first application correspondence information in the terminal.
  • the information of the application negotiated between the two is acquired, and the compression mode is determined based on the acquired information of the negotiated application.
  • the high compression mode can be appropriately applied in an environment that supports ECN.
  • FIG. 1 is a diagram illustrating the relationship between the state transition of RoHC and the header compression rate.
  • FIG. 2 is a diagram showing a static part and a dynamic part of IPv4, IPv6, UDP, and RTP headers used in RoHC.
  • FIG. 3 is a diagram illustrating an example in which ECN negotiation is performed using an SDP offer and an SDP answer.
  • FIG. 4A is a diagram illustrating an example of congestion control using ECN.
  • FIG. 4B is a diagram illustrating an example of congestion control using ECN.
  • FIG. 5 is a block diagram illustrating a configuration example of a terminal according to an embodiment of the present disclosure.
  • FIG. 6 is a block diagram illustrating a configuration example of a base station according to an embodiment of the present disclosure.
  • FIG. 1 is a diagram illustrating the relationship between the state transition of RoHC and the header compression rate.
  • FIG. 2 is a diagram showing a static part and a dynamic part of IPv4, IPv6, UDP, and RTP header
  • FIG. 7A is a diagram illustrating an example of a notification method of application correspondence information according to an embodiment of the present disclosure.
  • FIG. 7B is a diagram illustrating an example of a notification method of application correspondence information according to an embodiment of the present disclosure.
  • FIG. 8A is a diagram illustrating an example of a usage application information notification method according to an embodiment of the present disclosure.
  • FIG. 8B is a diagram illustrating an example of a usage application information notification method according to an embodiment of the present disclosure.
  • FIG. 9 is a diagram illustrating an example of a high compression mode for ECN according to an embodiment of the present disclosure.
  • FIG. 10A is a diagram illustrating an example of a method of controlling a use application at the time of handover according to an embodiment of the present disclosure.
  • FIG. 10A is a diagram illustrating an example of a method of controlling a use application at the time of handover according to an embodiment of the present disclosure.
  • FIG. 10B is a diagram illustrating an example of a method for controlling a use application at the time of handover according to an embodiment of the present disclosure.
  • FIG. 11 is a diagram illustrating an example of a high compression mode for MMCMH according to another embodiment of the present disclosure.
  • a case where a base station that does not support ECN is included in a plurality of base stations existing on a communication path between terminals that perform congestion notification using ECN is also assumed.
  • the base station 406 does not know the reason for the change that occurs in the IP header (change of ECN bit). Absent. For this reason, the base station 406 may not transmit the ECN bit in the IP header by applying a high compression mode that omits the IP header.
  • the base station 406 may change the RoHC compression mode to a low compression mode such as IR or IR-DYN for transmission regardless of the congestion notification using ECN.
  • the compression mode when ECN is used there is no provision in the specification regarding the compression mode when ECN is used, and it is implementation-dependent. Therefore, even if a base station existing on a communication path between terminals that perform congestion notification using ECN is compatible with ECN, depending on the implementation, the base station may perform IR or IR at the time of congestion notification using ECN. There is a possibility of changing to a low compression mode such as DYN.
  • congestion notification using ECN when congestion notification using ECN is performed, congestion due to ECN is not normally notified or is changed to a low compression mode, and congestion notification is frequently generated, so that radio resources are wasted. Consume.
  • an object of one embodiment of the present disclosure is to appropriately apply the high compression mode in an environment that supports ECN. As a result, frequent occurrence of congestion notification can be prevented, and wasteful consumption of radio resources can be suppressed.
  • FIG. 400 a communication system that includes terminals 400 and 402 and base stations 404 and 406 and performs communication between the terminal 400 and the terminal 402 will be described as shown in FIG.
  • FIG. 5 is a block diagram showing a configuration of terminals 400 and 402 according to the present embodiment. In FIG. 5, only components that are closely related to the present disclosure are shown, and conventional functions and the like of the terminal are omitted.
  • radio receiving section 500 receives signaling or data transmitted from base stations 404 and 406, etc., and receives the received signaling or data to corresponding components of terminals 400 and 402. Output.
  • the radio transmission unit 501 transmits signaling or data input from each component to the base stations 404, 406, and the like.
  • the application correspondence information acquisition unit 502 acquires application correspondence information indicating an application supported by the base stations 404 and 406 and a function related to the application. For example, when the base stations 404 and 406 support ECN, the application support information includes ECN.
  • the application correspondence information notification unit 503 notifies the base stations 404 and 406 of application correspondence information indicating the application supported by the own device (terminals 400 and 402) and the function related to the application.
  • the application-corresponding information notification unit 503 is related to an application (or an application) indicated in the application-corresponding information of the base stations 404 and 406 among the applications (or functions related to the application) supported by the own device (terminals 400 and 402).
  • Application matching the function is notified to the base stations 404 and 406 as application correspondence information of the terminals 400 and 402.
  • the use application negotiation unit 504 negotiates with the communication partner terminal an application used for communication and a function related to the application based on the application correspondence information of the base stations 404 and 406 acquired by the application correspondence information acquisition unit 502. Specifically, the use application negotiation unit 504 negotiates with the communication partner terminal about the use of an application that matches the application indicated in the application correspondence information acquired from the base stations 404 and 406 among the applications supported by the own device. For example, the use application negotiation unit 504 negotiates whether or not to use ECN when the base stations 404 and 406 support ECN, and uses ECN when the base stations 404 and 406 do not support ECN. Do not negotiate whether or not to do.
  • the use application information notification unit 505 negotiates with the use application negotiation unit 504 to determine an application used by the terminals 400 and 402 or a function related to the application (hereinafter, simply referred to as “use application”).
  • use application a function related to the application
  • the base station 404 and 406 are notified of the usage application information to be shown.
  • the compression mode determination unit 506 determines the header compression mode based on the usage application negotiated by the usage application negotiation unit 504. For example, when the application to be used is ECN, the compression mode determination unit 506 may determine a compression mode suitable for ECN. For example, a compression mode suitable for ECN includes a mode having the highest compression rate including a field for notifying an ECN bit.
  • the use application control unit 507 determines to stop or continue the application being used based on the application to which the handover destination base stations 404 and 406 correspond. In addition, after stopping the application, the use application control unit 507 determines to resume use of the application when performing handover again to the base stations 404 and 406 corresponding to the stopped application.
  • the use application control unit 507 negotiates with the communication partner terminal regarding the stop or restart of the use application. In addition, the use application control unit 507 notifies the base stations 404 and 406 of use application control information indicating contents (stop or restart) determined through negotiation.
  • FIG. 6 is a block diagram showing a configuration of base stations 404 and 406 according to the present embodiment. In FIG. 6, only components that are closely related to the present disclosure are shown, and conventional functions of the base station are omitted.
  • receiving section 600 receives signaling or data transmitted from terminals 400 and 402 or core network 412, and receives the received signaling or data corresponding to base stations 404 and 406. Output to the component.
  • the transmission unit 601 transmits signaling or data input from each component unit to the terminals 400 and 402 or the core network 412.
  • the application correspondence information notification unit 602 notifies the terminals 400 and 402 of application correspondence information indicating the application supported by the own device (base stations 404 and 406) and functions related to the application.
  • the application correspondence information acquisition unit 603 acquires application correspondence information indicating applications supported by the terminals 400 and 402 and functions related to the applications.
  • the application correspondence information of the terminals 400 and 402 includes an application that matches the application (or function related to the application) supported by the base stations 404 and 406 among the applications (or functions related to the application) supported by the terminals 400 and 402. included.
  • the use application information acquisition unit 604 obtains use application information indicating an application (use application) used in communication by the terminals 400 and 402, which is determined by negotiation with the communication partner terminal in the terminals 400 and 402. , 402.
  • the compression mode determination unit 605 determines the header compression mode based on the usage application indicated in the usage application information acquired by the usage application information acquisition unit 604.
  • the usage application control information acquisition unit 606 acquires usage application control information indicating the content (stopping or resuming the usage application) determined and negotiated by the terminals 400 and 402. Then, the use application control information acquisition unit 606 controls (stops or restarts) the function of the application used by the terminals 400 and 402 based on the acquired use application control information.
  • [Notification method of application support information] 7A and 7B show an example of a method for notifying the application correspondence information of the base stations 404 and 406 and the application correspondence information of the terminals 400 and 402.
  • FIG. 7A and 7B show an example of a method for notifying the application correspondence information of the base stations 404 and 406 and the application correspondence information of the terminals 400 and 402.
  • FIGS. 7A and 7B are performed before, for example, negotiation of application use by the terminals 400 and 402.
  • FIG. 7A uses a signaling message related to RRC (Radio Resource Control) connection and establishment described in Non-Patent Document 7.
  • RRC Radio Resource Control
  • the application correspondence information notification unit 602 of the base stations 404 and 406 includes application correspondence information indicating an application supported by the base stations 404 and 406 such as ECN in the RRCConnectionSetup signaling. And notifies the terminals 400 and 402 via the transmission unit 601.
  • support information whether or not the base stations 404 and 406 support header compression suitable for the corresponding application, and which header compression mode is used in the case of support. Such information may be included.
  • the application correspondence information acquisition unit 502 analyzes the RRCConnectionSetup signaling. Then, when the application correspondence information of the base stations 404 and 406 is included, the application correspondence information acquisition unit 502 compares the application correspondence information with the application supported by the own device (terminal 400 or 402), The application correspondence information of the terminals 400 and 402 indicating the matching application is generated.
  • the application correspondence information notification unit 503 of the terminals 400 and 402 includes the application correspondence information of the terminals 400 and 402 in the RRCConnectionSetupComplete signaling and notifies the base stations 404 and 406 via the wireless transmission unit 501.
  • the application correspondence information acquisition unit 603 analyzes the RRCConnectionSetupComplete signaling and includes the application correspondence information of the terminals 400 and 402. If yes, the application correspondence information is acquired.
  • FIG. 7B uses signaling messages related to System information acquisition and UE capacity transfer described in Non-Patent Document 7.
  • the application correspondence information notification unit 602 of the base stations 404 and 406 includes application correspondence information indicating an application supported by the base stations 404 and 406 such as ECN in the SystemInformationBlock (SIB) signaling, and the transmission unit Notification is made to the terminals 400 and 402 via 601.
  • SIB SystemInformationBlock
  • support information whether or not the base stations 404 and 406 support header compression suitable for the corresponding application, and which header compression mode is used in the case of support. Such information may be included.
  • the application correspondence information acquisition unit 502 analyzes the SystemInformationBlock signaling. Then, when the application correspondence information of the base stations 404 and 406 is included, the application correspondence information acquisition unit 502 compares the application correspondence information with the application supported by the own device (terminal 400 or 402), The application correspondence information of the terminals 400 and 402 indicating the matching application is generated.
  • the application correspondence information acquisition unit 603 of the base stations 404 and 406 includes an application correspondence information request for requesting provision of application correspondence information of the terminals 400 and 402 in the UECapabilityEnquiry signaling, and the terminal 400 via the transmission unit 601. , 402 is notified.
  • the radio reception unit 500 receives UECapabilityEnquiry signaling (application correspondence information request) transmitted from the base stations 404 and 406, the application correspondence information notification unit 503 is generated by the application correspondence information acquisition unit 502.
  • the application correspondence information of the terminals 400 and 402 is included in UECapabilityInformation signaling and notified to the base stations 404 and 406 via the wireless transmission unit 501.
  • the application correspondence information acquisition unit 603 analyzes the UECapabilityInformation signaling and includes the application correspondence information of the terminals 400 and 402. If yes, the application correspondence information is acquired.
  • the base stations 404 and 406 can specify the applications that can be used by the terminals 400 and 402.
  • non-patent As a method for notifying the application correspondence information of the base stations 404 and 406 and the application correspondence information of the terminals 400 and 402 before the terminals 400 and 402 start communication, non-patent
  • the method using signaling described in Document 7 is shown as an example.
  • the signaling used to notify the application correspondence information is not limited to these, and for example, MAC CE (MAC Control Element) described in Non-Patent Document 8 may be used.
  • the use application negotiation unit 504 performs an SDP offer based on the application correspondence information of the base stations 404 and 406 acquired by the application correspondence information acquisition unit 502. Create
  • the use application negotiation unit 504 may include the ECN in the SDP offer if the own device supports the ECN ( For example, see FIG.
  • the use application negotiation unit 504 does not include the ECN in the SDP offer even if the own device supports the ECN. That is, the use application negotiation unit 504 creates an SDP offer including ECN only when both the base stations 404 and 406 and the own device support ECN.
  • the SDP offer created by the use application negotiation unit 504 is transmitted to the communication partner terminals 400 and 402 via the wireless transmission unit 500.
  • the used application negotiation unit 504 of the terminals 400 and 402 that received the SDP offer by the wireless reception unit 501 creates an SDP answer based on the application correspondence information of the base stations 404 and 406 acquired by the application correspondence information acquisition unit 502 To do.
  • the use application negotiation unit 504 determines that the own device is compatible with the ECN. For example, ECN is included in the SDP answer (see, eg, FIG. 3).
  • the use application negotiation unit 504 includes the ECN in the SDP offer and the own device supports the ECN. Even in this case, ECN is not included in the SDP answer. That is, the utilization application negotiation unit 504 creates an SDP answer including ECN only when both the base stations 404 and 406 and the own device support ECN and the SDP offer includes ECN.
  • the SDP answer created by the use application negotiation unit 504 is transmitted to the communication partner terminals 400 and 402 via the wireless transmission unit 501.
  • both terminals 400 and 402 that perform communication correspond to ECN and the base stations 404 and 406 existing on the communication path of the terminals 400 and 402 correspond to ECN
  • negotiation is performed.
  • the use of ECN is determined.
  • the terminals 400 and 402 that perform communication can use ECN, if the base stations 404 and 406 existing on the communication path do not support ECN, the terminals 400 and 402 are connected. Will not negotiate ECN usage.
  • congestion can be normally notified by ECN.
  • FIG. 8A and FIG. 8B show an example of a method for notifying usage application information from the terminals 400 and 402 to the base stations 404 and 406.
  • FIG. 8A a signaling message related to RRC connection reconfiguration described in Non-Patent Document 7 is used.
  • the radio reception unit 500 performs RRCConnectionReconfiguration signaling transmitted from the base stations 404 and 406 in order to set a radio bearer for data transmission / reception of communication using an application.
  • the usage application information notification unit 505 includes all or part of the usage application information determined by the usage application negotiation unit 504 (for example, ECN usage) in the RRCConnectionReconfigurationComplete signaling and wirelessly transmits it. Notification is made to the base stations 404 and 406 via the unit 501.
  • the use application information notification unit 505 waits for the completion of the negotiation. Send RRCConnectionReconfigurationComplete signaling.
  • the usage application information acquisition unit 604 analyzes the RRCConnectionReconfigurationComplete signaling, and when the usage application information is included, Get application information.
  • Non-Patent Document 9 a signaling message related to Dedicated bearer activation described in Non-Patent Document 9 is used.
  • IMS IP Multimedia Subsystem
  • P-CSCF Proxy-Call Session Control Function
  • the P-CSCF notifies all or a part of the usage application information (for example, ECN usage) to a PCRF (Policy and Charging Rules Function) that is a network node on the LTE core network 412. Further, the PCRF notifies the application application information to a P-GW (Packet Data Network Gateway) which is a network node on the LTE core network 412.
  • the P-GW that has received all or part of the use application information transmits the use application information included in the signaling of the dedicated Bearer Establishment process for setting the data transmission / reception bearer for communication using the application.
  • the usage application information acquisition unit 604 analyzes the signaling of the dedicated Bearer Establishment process, and if the usage application information is included, Get application information.
  • the application information indicating the application negotiated with the communication partner terminal based on the application correspondence information of the base stations 404 and 406 in the terminals 400 and 402 is notified to the base stations 404 and 406.
  • the base stations 404 and 406 can confirm, for example, that the negotiation has been normally performed in the terminals 400 and 402 based on the application to which the base stations 404 and 406 correspond.
  • the base stations 404 and 406 can change the header compression mode based on the application used by the terminals 400 and 402 (details will be described later).
  • the terminals 400 and 402 set the QCI (QoS Class Identifier) according to the used application and notify the set QCI instead of including the used application information in the signaling of the dedicated Bearer establishment as shown in FIG. 8B. May notify the application used.
  • the QCI of a VoLTE data transmission / reception bearer is “1”.
  • the base stations 404 and 406 may receive information corresponding to ECN (the ECN bit of the IP header is “01” or “0” in the IP packet transmitted by the terminal 400 or 402 that has started communication). By including 10 ′′), it may be specified that the ECN is included in the use application. In other words, the used application information acquisition unit 604 implicitly acquires the used application information including the ECN by specifying the contents of the ECN bit. In this case, signaling as shown in FIGS. 8A and 8B for notification of the application information to be used is not necessary.
  • compression mode determination method Next, a method for determining the header compression mode in the compression mode determination unit 506 of the terminals 400 and 402 and the compression mode determination unit 605 of the base stations 404 and 406 will be described.
  • the compression mode determination unit 506 and the compression mode determination unit 605 determine a header compression mode suitable for the usage application based on the usage application information (that is, the negotiation result of the application between the terminals 400 and 402).
  • the compression mode determination unit 506 and the compression mode determines a compression mode to be applied according to the header compression mode included in the application correspondence information.
  • FIG. 9 shows an example of the RoHC high compression mode when using ECN in VoLTE as the application to be used.
  • ECN uses the lower 2 bits of the ToS field (in the case of IPv4) or the Traffic Class field (in the case of IPv6) of the IP header.
  • a RoHC high compression mode suitable for ECN use a high compression mode that can include only the ToS field or the Traffic Class field may be used.
  • an extension flag (X) is set in the high compression mode, an IP header extension is prepared, and a specific field (ToS field or TrafficTrClass field) is included in the IP header extension. Can do.
  • the compression mode determination unit 506 and the compression mode determination unit 605 may select a mode corresponding to the extension flag in the high compression mode.
  • a Traffic Class field is added to the IP header extension.
  • the terminals 400 and 402 can determine the compression mode suitable for the application determined in consideration of the application to which the base stations 404 and 406 correspond. Further, the base stations 404 and 406 can determine a header compression mode suitable for the application determined by the terminal 400 and 402 through negotiation. For example, when the terminals 400 and 402 use ECN, the base stations 404 and 406 can appropriately determine the RoHC compression mode corresponding to the congestion notification using ECN.
  • the RoHC high compression mode suitable for ECN use is not limited to the UOR-2 mode, and is a high compression mode that can include a field (for example, a ToS field or a traffic class field) used for transmission of ECN bits. I just need it.
  • the compression mode determination unit 506 and the compression mode determination unit 605 may select the mode with the highest compression rate among the high compression modes that can include the ToS field or the Traffic Class field.
  • FIG. 10A and FIG. 10B show processing related to control of the applications used by the terminals 400 and 402 when the terminals 400 and 402 are handed over to other base stations 404 and 406.
  • the use application control unit 507 of the terminals 400 and 402 determines that the handover destination base stations 404 and 406 are based on the application correspondence information of the handover destination base stations 404 and 406 (for example, called target eNodeB). Obtains information indicating whether or not is compatible with the currently used application.
  • This information may be included in the RRCConnectionReconfiguration information transmitted immediately before the handover from the handover source base stations 404 and 406 (for example, called “serving eNodeB”).
  • the SystemInformationBlock or the MAC CE sent from the handover destination base stations 404 and 406 May be included.
  • the use application control unit 507 determines whether the header compression mode used by the handover destination base stations 404 and 406 corresponds to the application being used by the terminals 400 and 402, thereby determining the handover destination base station 404. , 406 may implicitly determine whether or not it corresponds to the currently used application.
  • the terminals 400 and 402 determine that the use application is to be continuously used (ST202 in FIG. 10B).
  • step ST101 in FIG. 10A the terminals 400 and 402 determine to stop using the application or part of the application function (for example, ECN) (ST102 in FIG. 10A). Then, terminals 400 and 402 notify the communication partner terminal of use application control information indicating that the function of the use application is to be stopped (ST103 in FIG. 10A).
  • the communication partner terminal receives the use application control information indicating that the function of the use application is to be stopped, the communication partner terminal stops using the ECN.
  • the terminals 400 and 402 transmit the ECN bit used so far to “00” indicating non-ECN support. May be.
  • the application application control unit 507 of the terminals 400 and 402 transmits the SDP offer again to the communication partner terminals 400 and 402 before transmitting the ECN bit as “00”, and ECN is performed by the SDP offer and the SDP answer. You may negotiate a stop.
  • the terminals 400 and 402 determine to resume the stopped application being used in the handover destination base stations 404 and 406 (ST202 in FIG. 10B).
  • the terminals 400 and 402 inquire the communication partner terminals 400 and 402 to resume the application used at the start of communication (ST203 in FIG. 10B).
  • the terminals 400 and 402 may transmit the ECN bit set to “01” or “10” indicating ENC correspondence.
  • the application application control unit 507 of the communication partner terminal 400 or 402 that has received the IP packet having the ECN bit “01” or “10” does not have any problem even if the ECN is restarted, the ECN bit is changed to the ECN correspondence.
  • the IP packet is sent back with “01” or “10” shown.
  • the stations 404 and 406 also support ECN.
  • the application control unit 507 of the communication partner terminals 400 and 402 sets the ECN bit to “00” indicating non-correspondence and sends back an IP packet.
  • the use application control information acquisition unit 606 of the base stations 404 and 406 receives the IP packet whose ECN bit is “01” or “10”. ECN restart information is acquired. As a result, the base stations 404 and 406 resume the function of the stopped ECN.
  • the use application control unit 507 of the terminals 400 and 402 transmits the SDP offer to the communication partner terminals 400 and 402 again, and the SDP offer. And ECN resumption may be negotiated by the SDP answer.
  • the terminals 400 and 402 control the continuation, stop or restart of the application to be used based on the application to which the handover destination base stations 404 and 406 correspond. Accordingly, the terminals 400 and 402 can negotiate the use of the application on the data path established with the communication partner terminal without using the SDP offer and the SDP answer at every handover.
  • terminals 400 and 402 acquire application correspondence information indicating applications to which base stations 404 and 406 existing on a communication path with a communication partner terminal correspond, and the own device supports Among the applications to be used, the use of an application that matches the application indicated in the application correspondence information of the base stations 404 and 406 is negotiated with the communication partner terminal, and the header compression mode is determined based on the negotiated application.
  • the terminals 400 and 402 are included. Do not negotiate the use of ECN. Therefore, it is possible to prevent the base station existing on the communication path between the terminals 400 and 402 from applying the high compression mode in which the IP header is omitted and ECN bits in the IP header from being transmitted. .
  • the terminals 400 and 402 and the base stations 404 and 406 determine the header compression mode based on the negotiated application (for example, ECN). As a result, even when the RoHC high compression mode is applied, it is possible to use the high compression mode (for example, see FIG. 9) in consideration of notification of the ECN bit. In other words, it is possible to prevent the RoHC compression mode from being changed to the low compression mode regardless of congestion notification using ECN.
  • ECN negotiated application
  • the high compression mode can be appropriately applied in an environment that supports ECN.
  • congestion can be normally notified by ECN in the high compression mode, frequent occurrence of congestion notification can be prevented and wasteful consumption of radio resources can be suppressed.
  • the applications used by the terminals 400 and 402 are not limited to ECN, and other applications may be used.
  • FIG. 11 shows an example of a RoHC high compression mode suitable for using MMCMH in VoLTE.
  • MMCMH Multi-stream Multiparty Conferencing for Multimedia Telephony Service for MTSI: multi-stream compatible terminal
  • FIG. 11 shows an example of a RoHC high compression mode suitable for using MMCMH in VoLTE.
  • a high compression mode including a CID (Context ID) described in Non-Patent Document 2 may be used.
  • the base stations 404 and 406 may select the compression mode with the highest compression rate among the header compression modes having a field for transmitting the CID.
  • the upper limit (maxCID) of CID is set between terminals 400 and 402 and base stations 404 and 406 by the method described in Non-Patent Document 1 and Non-Patent Document 7. You may negotiate with.
  • the application correspondence information notification unit 602 of the base stations 404 and 406 may notify not only supported application information but also information on unsupported applications depending on the state of wireless quality. For example, when it is possible to allocate radio resources for a voice-only call (VoLTE) due to congestion of the radio access networks 408 and 410, but when it is difficult to allocate radio resources for video such as a videophone, the base stations 404 and 406 May notify the terminals 400 and 402 that the video is not supported or that the video cannot be temporarily supported by the method shown in FIG. 7A or 7B.
  • VoIP voice-only call
  • the base stations 404 and 406 May notify the terminals 400 and 402 that the video is not supported or that the video cannot be temporarily supported by the method shown in FIG. 7A or 7B.
  • the utilization application negotiation unit 504 of the terminals 400 and 402 Upon receiving this notification, the utilization application negotiation unit 504 of the terminals 400 and 402 does not include a media line related to video in the SDP offer or answer when starting communication, so that only a voice call, not a videophone call is made.
  • the application correspondence information acquisition unit 502 of the terminals 400 and 402 acquires that the video is not supported from the base stations 404 and 406 or that the video cannot be temporarily supported, the user of the terminals 400 and 402 is notified. In order to notify that the video cannot be used, information indicating that the video cannot be used may be displayed on the screen or the like.
  • the control unit 507 stops using the video by a method such as releasing resources allocated to the video bearer using UE requested bearer resource modification described in Non-Patent Document 9. Similarly, a method of reallocating resources to a video bearer can be applied to resuming video use. Further, instead of releasing and reallocating bearer resources, video may be stopped and resumed by exchanging SDP offers and SDP answers with communication partner terminals 400 and 402 and re-negotiating. . In order to inform the user of the terminal 400 or 402 when the video is stopped or restarted, a method of displaying on a screen or playing a sound may be used.
  • the method of the present disclosure is applicable only to the LTE network. is not.
  • the method of the present disclosure may be applied to a next generation network as described in Non-Patent Document 11.
  • the bearer in the case of the LTE network may be a slice of the next generation network.
  • each functional block used in the description of the above embodiment is typically realized as an LSI which 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 implementation with a dedicated circuit or a general-purpose processor is also possible.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used.
  • the terminal includes: an acquisition unit that acquires first application correspondence information indicating an application supported by a base station that exists on a communication path with a communication counterpart terminal; A negotiation unit that negotiates use of an application that matches the application indicated in the application correspondence information with the communication partner terminal, and a compression mode determination unit that determines a compression mode based on the negotiation result of the application.
  • a first notification unit that notifies the base station of second application correspondence information indicating an application that matches an application indicated in the first application correspondence information among applications supported by the own device, Is further provided.
  • the terminal of the present disclosure further includes a second notification unit that notifies the base station of usage application information indicating an application whose usage has been determined by the negotiation unit.
  • the terminal when the terminal performs handover, the terminal further includes a control unit that determines stop or continuation of the application being used based on information on the application to which the handover destination base station corresponds.
  • the control unit resumes use of the application when the terminal is handed over to a base station corresponding to the application.
  • the application is ECN (Explicit Congestion Notification)
  • the compression mode determination unit selects a mode having the highest compression rate among modes having a field for transmitting an ECN notification bit.
  • the field for transmitting the ECN notification bit is a ToS (Type of Service) field or a Traffic Class field.
  • the application is MMCMH (Multi-stream Multiparty Conferencing for Multimedia Telephony Service for MTSI)
  • the compression mode determination unit includes a compression rate among modes having a field for transmitting a CID (Context ID). Select the mode with the highest.
  • the base station of the present disclosure includes: a notification unit that notifies the terminal of first application correspondence information indicating an application supported by the own device; and a communication partner terminal of the terminal based on the first application correspondence information in the terminal.
  • An application information acquisition unit that acquires application information negotiated with each other, and a compression mode determination unit that determines a compression mode based on the acquired negotiated application information.
  • the communication method acquires first application correspondence information indicating an application to which a base station existing on a communication path between a terminal and a communication partner terminal corresponds, and the first corresponding application among the applications to which the terminal corresponds.
  • Use of an application that matches the application indicated in the application correspondence information is negotiated with the communication partner terminal, and the compression mode is determined based on the negotiation result of the application.
  • the communication method of the present disclosure notifies the terminal of first application correspondence information indicating an application supported by the base station, and negotiates with the communication partner terminal of the terminal based on the first application correspondence information at the terminal.
  • the acquired application information is acquired, and the compression mode is determined based on the acquired negotiated application information.
  • This disclosure is suitable for a communication system that selects an efficient header compression method for an application used for communication and application characteristics.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

端末は、通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得するアプリケーション対応情報取得部と、自機が対応するアプリケーションのうち、第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を通信相手端末と折衝する利用アプリケーション折衝部と、アプリケーションの折衝結果に基づいて圧縮モードを決定する圧縮モード決定部と、を具備する。

Description

端末、基地局及び通信方法
　本開示は、端末、基地局及び通信方法に関する。
　３ＧＰＰ（Third Generation Partnership Project）のＬＴＥ（Long Term Evolution）ネットワークにおける無線アクセス網の端末（ＵＥ（User Equipment）と呼ばれることもある）及び基地局（ｅＮＢ（e Node B）と呼ばれることもある）の間においてヘッダ圧縮（ＲｏＨＣ：Robust Header Compression）がサポートされている（例えば、非特許文献１を参照）。ＲｏＨＣは、非特許文献２等に規格化されている。ＲｏＨＣでは、ＩＰ(Internet Protocol)ヘッダ、ＵＤＰ(User Datagram Protocol)ヘッダ、ＲＴＰ(Real-time Transport Protocol)ヘッダ等に含まれる情報のうち、静的(static)なフィールドを省略したり、動的(dynamic)なフィールド中でも該当通信において変化し得ないフィールドを省略したりすること等により、ヘッダの圧縮を行う。
　図１は、ＲｏＨＣの状態遷移図を示す。ＲｏＨＣの状態には、ＩＲ（Initialization and Refresh）状態、ＦＯ（First Order）状態、ＳＯ（Second Order）状態の３つの状態が存在する。ＩＲ状態が最も低圧縮で、ＦＯ状態、ＳＯ状態になるほど高圧縮となる。
　図２は、一例として、（Ａ）ＩＰｖ４(IP version 4)ヘッダ、（Ｂ）ＩＰｖ６(IP version 6)ヘッダ、（Ｃ）ＵＤＰヘッダ、及び、（Ｄ）ＲＴＰヘッダの静的フィールド（Static part）及び動的フィールド（Dynamic part）の分類を示す。
　ＩＲ状態では、圧縮はほとんど行われず、端末は、静的情報及び動的情報を全て送信する。ＦＯ状態では、端末は、静的フィールドを圧縮し、動的フィールドを圧縮せずに送信する。ＳＯ状態では、端末は、動的フィールドでも該当通信でほとんど変化しないフィールド、又は他のフィールドの情報から再現できるフィールド情報を見極め、最低限のフィールドのみを簡略化した形で送信する。
　通信開始時にはＩＲ状態から始まり、送信側の判断又は受信側からのフィードバック情報により、ＦＯ状態又はＳＯ状態へと高圧縮モードに遷移する。ＦＯ状態からＳＯ状態に遷移する場合も同様である。反対に、例えば、圧縮期限のタイマが期限切れになった場合、又は、受信側からのフィードバック情報又は圧縮したフィールドに変化が生じた場合等にはＳＯ状態からＦＯ状態又はＩＲ状態、又はＦＯ状態からＩＲ状態へと低圧縮モードに遷移する。
　非特許文献２に記載の通り、低圧縮モードにはＩＲ及びＩＲ－ＤＹＮがあり、高圧縮モードにはＵＯ－０、Ｒ－０、Ｒ－０－ＣＲＣ、Ｒ－１、Ｒ－１－ＩＤ、Ｒ－１－ＴＳ、ＵＯ－１、ＵＯ－１－ＩＤ、ＵＯ－１－ＴＳ、ＵＯＲ－２、ＵＯＲ－２－ＩＤ、ＵＯＲ－２－ＴＳ等があり、高圧縮モードの中には拡張フィールドとして、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダの特定のフィールドを付加できるモードもある。
　ＬＴＥを用いた通信において、の圧縮モード（高圧縮モードと呼ぶこともある）が、例えばＶｏＬＴＥ(Voice over LTE)等で使われている。ＶｏＬＴＥでは、有音区間ではＲＴＰシーケンス番号及びＵＤＰチェックサム（ＩＰｖ６の場合）のみを送信することにより、ＩＰヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダを最大３バイトまで圧縮する（例えば、非特許文献３を参照）。また、ＶｏＬＴＥで使用する高圧縮モードでは、ＩＰヘッダの情報を含むことを想定していない。そのため、ＶｏＬＴＥでは、ＩＰヘッダの情報に変化があった場合の圧縮モードに関しては実装依存とされている。
　また、３ＧＰＰでは、ＶｏＬＴＥ等のリアルタイム通信の際、通信路の輻輳を端末に通知し、コーデックのビットレート変更を促す技術としてＥＣＮ（Explicit Congestion Notification）がサポートされている（例えば、非特許文献４及び非特許文献５を参照）。ＥＣＮは非特許文献６に規格化されている。
　ＥＣＮでは、ＩＰヘッダを利用して輻輳通知する場合、ＩＰｖ４のＴｏＳ(Type of Service)フィールド又はＩＰｖ６のTraffic Classフィールドの最下位２ビット（以下、ＥＣＮビットと呼ぶ）を利用する。非特許文献５によると、通信を行う端末同士は、接続先の基地局がＥＣＮに対応しているか否かにかかわらず、端末がＥＣＮに対応しているか否かの情報を、ＳＤＰ(Session Description Protocol)オファー及びＳＤＰアンサーを用いて通信直前に端末間で交換し、両端末でＥＣＮを利用するか否かを折衝する。図３は、非特許文献５に記載されたＥＣＮ折衝に関するＳＤＰオファー及びＳＤＰアンサーの一例を示す。
　ＥＣＮの利用が折衝された場合、一方の端末は、ＩＰヘッダのＥＣＮビットを“01”又は“10”に設定し、ＥＣＮに対応していることを基地局に通知し、ＥＣＮに対応している基地局が輻輳送信方向の輻輳を検出した場合には、基地局は、ＩＰヘッダのＥＣＮビットを“11”に設定し、輻輳が生じていることを他方の端末へ通知する。基地局から輻輳が生じていることを通知された端末は、通信相手端末に対して、コーデックのビットレートを下げるように要求シグナリングを送信する。
　図４Ａ及び図４Ｂは、ＥＣＮを用いた輻輳通知及びビットレート変更要求の一例を示す。図４Ａは、端末４００から端末４０２へのＩＰパケット送信において、基地局４０４によってコア網４１２方向の輻輳が検出された例を示し、図４Ｂは、端末４００から端末４０２へのＩＰパケット送信において、基地局４０６によって無線アクセス網４１０方向の輻輳が検出された例を示す。
　図４Ａでは、端末４００は、ＥＣＮに対応していることを示すために、ＩＰヘッダのＥＣＮビットを“10”に設定し、端末４０２へ送信する。端末４００から端末４０２への通信路上に存在する基地局４０４は、コア網４１２側の輻輳又は無線アクセス網４０８側の上り(uplink)方向の輻輳を検出し、ＩＰヘッダのＥＣＮビットを“11”に変更し、端末４０２へ送信する。端末４０２は、ＩＰヘッダのＥＣＮビットが“11”であることを検出すると、ビットレートを下げるように要求するビットレート変更要求を端末４００へ送信する。
　また、図４Ｂでは、端末４００は、ＥＣＮに対応していることを示すために、ＩＰヘッダのＥＣＮビットを“10”に設定し、端末４０２へ送信する。端末４００から端末４０２への通信路上に存在する基地局４０６は、無線アクセス網４１０側の下り(downlink)方向の輻輳を検出し、ＩＰヘッダのＥＣＮビットを“11”に変更し、端末４０２へ送信する。端末４０２は、ＩＰヘッダのＥＣＮビットが“11”であることを検出すると、ビットレートを下げるように要求するビットレート変更要求を端末４００に送信する。なお、この処理は、端末４０２から端末４００へのＩＰパケット送信においても同様である。
3GPP TS 36.323 v13.2.1, "Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification" IETF RFC 3095, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", C. Bormann, Editor 3GPP R2-084764, "LS on considerations on transport block sizes for VoIP" 3GPP TS 36.300 v13.4.0, "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2" 3GPP TS 26.114 v14.0.0, "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction" IETF RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP", K. Ramakrishnan, S. Floyd and D. Black 3GPP TS 36.331 v13.2.0, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification" 3GPP TS 36.321 v13.2.0, "Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification" 3GPP TS 23.401 v14.0.0, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access" 3GPP TR 26.980 v13.0.0, "Media handling aspects of multi-stream multiparty conferencing for Multimedia Telephony Service for IMS (MTSI)" 3GPP TR 23.799 v0.6.0, "Study on Architecture for Next Generation System"
　上述したように、ＶｏＬＴＥの高圧縮モードではＩＰヘッダを含むことが想定されていない。一方で、ＥＣＮでは、ＩＰヘッダを用いて輻輳の通知を行う。よって、ＥＣＮをサポートする環境において高圧縮モードを適用することは困難である。
　本開示の非限定的な実施例は、ＥＣＮをサポートする環境において高圧縮モードを適切に適用することができる端末、基地局及び通信方法を提供することである。
　本開示の一態様に係る端末は、通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得する取得部と、自機が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝する折衝部と、前記アプリケーションの折衝結果に基づいて圧縮モードを決定する圧縮モード決定部と、を具備する。
　本開示の一態様に係る基地局は、自機が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知する通知部と、前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得するアプリケーション情報取得部と、前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する圧縮モード決定部と、を具備する。
　本開示の一態様に係る通信方法は、端末と通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得し、前記端末が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝し、前記アプリケーションの折衝結果に基づいて圧縮モードを決定する。
　本開示の一態様に係る通信方法は、基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知し、前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得し、前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する。
　なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　本開示の一態様によれば、ＥＣＮをサポートする環境において高圧縮モードを適切に適用することができる。
　本開示の一態様における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
図１は、ＲｏＨＣの状態遷移とヘッダ圧縮率の関係を示す図である。 図２は、ＲｏＨＣで用いる、ＩＰｖ４、ＩＰｖ６、ＵＤＰ及びＲＴＰヘッダの、静的部分と動的部分を示す図である。 図３は、ＳＤＰオファー及びＳＤＰアンサーでＥＣＮ折衝を行う一例を示す図である。 図４Ａは、ＥＣＮを用いた輻輳制御の一例を示す図である。 図４Ｂは、ＥＣＮを用いた輻輳制御の一例を示す図である。 図５は、本開示の一実施の形態に係る端末の構成例を示すブロック図である。 図６は、本開示の一実施の形態に係る基地局の構成例を示すブロック図である。 図７Ａは、本開示の一実施の形態に係るアプリケーション対応情報の通知方法の一例を示す図である。 図７Ｂは、本開示の一実施の形態に係るアプリケーション対応情報の通知方法の一例を示す図である。 図８Ａは、本開示の一実施の形態に係る利用アプリケーション情報の通知方法の一例を示す図である。 図８Ｂは、本開示の一実施の形態に係る利用アプリケーション情報の通知方法の一例を示す図である。 図９は、本開示の一実施の形態に係るＥＣＮに対する高圧縮モードの一例を示す図である。 図１０Ａは、本開示の一実施の形態に係るハンドオーバ時の利用アプリケーションの制御方法の一例を示す図である。 図１０Ｂは、本開示の一実施の形態に係るハンドオーバ時の利用アプリケーションの制御方法の一例を示す図である。 図１１は、本開示の他の実施の形態に係るＭＭＣＭＨに対する高圧縮モードの一例を示す図である。
　［本開示の一態様に至る経緯］
　ＥＣＮを用いた輻輳通知を行う端末間の通信経路上に存在する複数の基地局の中にＥＣＮに対応していない基地局が含まれる場合も想定される。例えば、図４Ａの例において、基地局４０６（又は基地局４０４の場合もある）がＥＣＮに対応していない場合、基地局４０６は、ＩＰヘッダに生じる変化（ＥＣＮビットの変更）の理由が分からない。このため、基地局４０６は、ＩＰヘッダを省略するような高圧縮モードを適用してＩＰヘッダ内のＥＣＮビットを送信しない可能性がある。または、基地局４０６は、ＥＣＮを用いた輻輳通知に関係無く、ＲｏＨＣの圧縮モードをＩＲ又はＩＲ－ＤＹＮ等の低圧縮モードに変更して送信する可能性もある。
　また、ＥＣＮを用いた場合の圧縮モードに関する仕様上の規定はなく実装依存である。よって、ＥＣＮを用いた輻輳通知を行う端末間の通信経路上に存在する基地局がＥＣＮに対応していても、実装によっては、基地局は、ＥＣＮを用いた輻輳通知の際にＩＲ又はＩＲ－ＤＹＮ等の低圧縮モードに変更する可能性もあり得る。
　このように、ＥＣＮを用いた輻輳通知を行う際、ＥＣＮによる輻輳が正常に通知されなかったり、低圧縮モードに変更されたりして、輻輳通知が頻繁に発生することにより、無線リソースを無駄に消費してしまう。
　そこで、本開示の一態様では、ＥＣＮをサポートする環境において高圧縮モードを適切に適用することを目的とする。これにより、輻輳通知が頻繁に発生することを防ぎ、無線リソースの無駄な消費を抑えることができる。
　以下、本開示の実施の形態について、図４～図１１を参照して詳細に説明する。
　以下では、一例として、図４に示すように、端末４００，４０２、基地局４０４，４０６を含み、端末４００と端末４０２との間で通信を行う通信システムについて説明する。
　［端末の構成］
　図５は、本実施の形態に係る端末４００，４０２の構成を示すブロック図である。なお、図５では、本開示と密接に関連する構成部のみを示し、端末の従来の機能等は省略している。
　図５に示す端末４００，４０２において、無線受信部５００は、基地局４０４，４０６等から送信されるシグナリング又はデータを受信し、受信したシグナリング又はデータを、端末４００，４０２の対応する構成部へ出力する。無線送信部５０１は、各構成部から入力されるシグナリング又はデータを基地局４０４，４０６等へ送信する。
　アプリケーション対応情報取得部５０２は、基地局４０４、４０６が対応しているアプリケーション及びアプリケーションに関連する機能を示すアプリケーション対応情報を取得する。例えば、基地局４０４，４０６がＥＣＮに対応する場合、アプリケーション対応情報にはＥＣＮが含まれる。
　アプリケーション対応情報通知部５０３は、基地局４０４，４０６に対して、自機（端末４００，４０２）が対応しているアプリケーション及びアプリケーションに関連する機能を示すアプリケーション対応情報を通知する。例えば、アプリケーション対応情報通知部５０３は、自機（端末４００，４０２）が対応するアプリケーション（又はアプリケーションに関する機能）のうち、基地局４０４，４０６のアプリケーション対応情報に示されるアプリケーション（又はアプリケーションに関連する機能）と一致するアプリケーションを、端末４００，４０２のアプリケーション対応情報として、基地局４０４，４０６へ通知する。
　利用アプリケーション折衝部５０４は、アプリケーション対応情報取得部５０２が取得した、基地局４０４，４０６のアプリケーション対応情報に基づいて、通信で利用するアプリケーション及びアプリケーションに関する機能を通信相手端末との間で折衝する。具体的には、利用アプリケーション折衝部５０４は、自機が対応するアプリケーションのうち、基地局４０４，４０６から取得したアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を通信相手端末と折衝する。例えば、利用アプリケーション折衝部５０４は、基地局４０４，４０６がＥＣＮに対応する場合にはＥＣＮを利用するか否かを折衝する一方、基地局４０４，４０６がＥＣＮに対応しない場合にはＥＣＮを利用するか否かを折衝しない。
　利用アプリケーション情報通知部５０５は、利用アプリケーション折衝部５０４によって折衝して決定された、端末４００，４０２が通信で利用するアプリケーション又はアプリケーションに関する機能（以下、単に「利用アプリケーション」と呼ぶこともある）を示す利用アプリケーション情報を基地局４０４、４０６に通知する。
　圧縮モード決定部５０６は、利用アプリケーション折衝部５０４で折衝された利用アプリケーションに基づいてヘッダ圧縮モードを決定する。例えば、圧縮モード決定部５０６は、利用アプリケーションがＥＣＮの場合、ＥＣＮに適した圧縮モードを決定してもよい。例えば、ＥＣＮに適した圧縮モードとしては、ＥＣＮビットを通知するフィールドを含む圧縮率が最も高いモード等が挙げられる。
　利用アプリケーション制御部５０７は、例えば、ハンドオーバを行う際に、ハンドオーバ先の基地局４０４，４０６が対応するアプリケーションに基づいて、利用中のアプリケーションの停止又は継続を決定する。また、利用アプリケーション制御部５０７は、アプリケーションを停止した後、停止中のアプリケーションに対応する基地局４０４，４０６へ再びハンドオーバする場合、当該アプリケーションの利用の再開を決定する。そして、利用アプリケーション制御部５０７は、利用アプリケーションの停止又は再開を決定した場合、通信相手端末との間で利用アプリケーションの停止又は再開に関する折衝を行う。また、利用アプリケーション制御部５０７は、折衝して決定した内容（停止又は再開等）を示す利用アプリケーション制御情報を基地局４０４，４０６に通知する。
　［基地局の構成］
　図６は、本実施の形態に係る基地局４０４，４０６の構成を示すブロック図である。なお、図６では、本開示と密接に関連する構成部のみを示し、基地局の従来の機能等は省略している。
　図６に示す基地局４０４，４０６において、受信部６００は、端末４００，４０２又はコア網４１２から送信されるシグナリング又はデータを受信し、受信したシグナリング又はデータを、基地局４０４，４０６の対応する構成部へ出力する。送信部６０１は、各構成部から入力されるシグナリング又はデータを、端末４００，４０２又はコア網４１２へ送信する。
　アプリケーション対応情報通知部６０２は、自機（基地局４０４、４０６）が対応するアプリケーション及びアプリケーションに関連する機能を示すアプリケーション対応情報を端末４００、４０２に通知する。
　アプリケーション対応情報取得部６０３は、端末４００、４０２が対応しているアプリケーション及びアプリケーションに関連する機能を示すアプリケーション対応情報を取得する。例えば、端末４００，４０２のアプリケーション対応情報には、端末４００，４０２が対応するアプリケーション（又はアプリケーションに関する機能）のうち、基地局４０４，４０６が対応するアプリケーション（又はアプリケーションに関する機能）と一致するアプリケーションが含まれる。
　利用アプリケーション情報取得部６０４は、端末４００，４０２において通信相手端末との間で折衝して決定された、端末４００，４０２が通信で利用するアプリケーション（利用アプリケーション）を示す利用アプリケーション情報を、端末４００、４０２から取得する。
　圧縮モード決定部６０５は、利用アプリケーション情報取得部６０４が取得した利用アプリケーション情報に示される利用アプリケーションに基づいてヘッダ圧縮モードを決定する。
　利用アプリケーション制御情報取得部６０６は、端末４００、４０２が決定・折衝した内容（利用アプリケーションの停止又は再開）を示す利用アプリケーション制御情報を取得する。そして、利用アプリケーション制御情報取得部６０６は、取得した利用アプリケーション制御情報に基づいて、端末４００，４０２が利用するアプリケーションの機能を制御（停止又は再開等）する。
　［アプリケーション対応情報の通知方法］
　図７Ａ及び図７Ｂは、基地局４０４，４０６のアプリケーション対応情報及び端末４００，４０２のアプリケーション対応情報を通知する方法の一例を示す。
　図７Ａ及び図７Ｂに示す動作は、例えば、端末４００，４０２によるアプリケーション利用の折衝前に行われる。
　図７Ａは、非特許文献７に記載のRRC (Radio Resource Control) connection establishmentに係るシグナリングメッセージを用いる。
　具体的には、RRC connection establishmentの際、基地局４０４、４０６のアプリケーション対応情報通知部６０２は、ＥＣＮ等の基地局４０４，４０６が対応しているアプリケーションを示すアプリケーション対応情報をRRCConnectionSetupシグナリングに含めて、送信部６０１を介して端末４００、４０２へ通知する。
　なお、このアプリケーション対応情報の中には、基地局４０４，４０６が対応するアプリケーションに適したヘッダ圧縮に対応しているか否か、また、対応している場合にはどのヘッダ圧縮モードを使用するか等の情報が含まれていてもよい。
　一方、端末４００、４０２では、無線受信部５００が基地局４０４、４０６から通知されるRRCConnectionSetupシグナリングを受信すると、アプリケーション対応情報取得部５０２は、RRCConnectionSetupシグナリングを解析する。そして、アプリケーション対応情報取得部５０２は、基地局４０４、４０６のアプリケーション対応情報が含まれている場合、当該アプリケーション対応情報と、自機（端末４００、４０２）が対応するアプリケーションとを比較して、一致するアプリケーションを示す、端末４００，４０２のアプリケーション対応情報を生成する。そして、端末４００、４０２のアプリケーション対応情報通知部５０３は、端末４００，４０２のアプリケーション対応情報をRRCConnectionSetupCompleteシグナリングに含めて、無線送信部５０１を介して基地局４０４、４０６へ通知する。
　基地局４０４、４０６では、受信部６００が端末４００、４０２から送信されるRRCConnectionSetupCompleteシグナリングを受信すると、アプリケーション対応情報取得部６０３はRRCConnectionSetupCompleteシグナリングを解析し、端末４００、４０２のアプリケーション対応情報が含まれている場合、当該アプリケーション対応情報を取得する。
　図７Ｂは、非特許文献７に記載のSystem information acquisition、及びUE capability transferに係るシグナリングメッセージを用いる。
　具体的には、基地局４０４、４０６のアプリケーション対応情報通知部６０２は、ＥＣＮ等の基地局４０４，４０６が対応しているアプリケーションを示すアプリケーション対応情報をSystemInformationBlock（ＳＩＢ）シグナリングに含めて、送信部６０１を介して端末４００、４０２へ通知する。
　なお、このアプリケーション対応情報の中には、基地局４０４，４０６が対応するアプリケーションに適したヘッダ圧縮に対応しているか否か、また、対応している場合にはどのヘッダ圧縮モードを使用するか等の情報が含まれていてもよい。
　一方、端末４００、４０２では、無線受信部５００が基地局４０４、４０６から通知されるSystemInformationBlockシグナリングを受信すると、アプリケーション対応情報取得部５０２は、SystemInformationBlockシグナリングを解析する。そして、アプリケーション対応情報取得部５０２は、基地局４０４、４０６のアプリケーション対応情報が含まれている場合、当該アプリケーション対応情報と、自機（端末４００、４０２）が対応するアプリケーションとを比較して、一致するアプリケーションを示す、端末４００，４０２のアプリケーション対応情報を生成する。
　その後、基地局４０４、４０６のアプリケーション対応情報取得部６０３は、端末４００、４０２のアプリケーション対応情報の提供を要求するためのアプリケーション対応情報要求をUECapabilityEnquiryシグナリングに含めて、送信部６０１を介して端末４００、４０２へ通知する。
　端末４００、４０２では、無線受信部５００が基地局４０４、４０６から送信されたUECapabilityEnquiryシグナリング（アプリケーション対応情報要求）を受信すると、アプリケーション対応情報通知部５０３は、アプリケーション対応情報取得部５０２で生成された端末４００，４０２のアプリケーション対応情報をUECapabilityInformationシグナリングに含めて、無線送信部５０１を介して基地局４０４、４０６へ通知する。
　基地局４０４、４０６では、受信部６００が端末４００、４０２から送信されるUECapabilityInformationシグナリングを受信すると、アプリケーション対応情報取得部６０３はUECapabilityInformationシグナリングを解析し、端末４００，４０２のアプリケーション対応情報が含まれている場合、当該アプリケーション対応情報を取得する。
　このようにして端末４００，４０２のアプリケーション対応情報を基地局４０４，４０６へ通知することにより、基地局４０４，４０６は、端末４００，４０２が利用可能なアプリケーションを特定することができる。
　なお、図７Ａ及び図７Ｂに示す例では、端末４００、４０２が通信開始前に、基地局４０４、４０６のアプリケーション対応情報、及び、端末４００、４０２のアプリケーション対応情報を通知する方法として、非特許文献７に記載のシグナリングを用いる方法を一例として示した。しかし、アプリケーション対応情報の通知に用いられるシグナリングは、これらに限定されず、例えば、非特許文献８に記載のＭＡＣ　ＣＥ（MAC Control Element）等を用いてもよい。
　［利用アプリケーションの折衝方法］
　次に、端末４００，４０２におけるアプリケーション利用のための通信相手端末との折衝について説明する。
　端末４００、４０２がアプリケーションを用いた通信、例えばＶｏＬＴＥ等を開始する際、利用アプリケーション折衝部５０４は、アプリケーション対応情報取得部５０２が取得した、基地局４０４、４０６のアプリケーション対応情報に基づいてＳＤＰオファーを作成する。
　例えば、基地局４０４，４０６のアプリケーション対応情報の中にＥＣＮが含まれている場合、利用アプリケーション折衝部５０４は、自機がＥＣＮに対応していれば、ＥＣＮをＳＤＰオファーに含めてもよい（例えば、図３を参照）。一方、基地局４０４，４０６のアプリケーション対応情報の中にＥＣＮが含まれていない場合、利用アプリケーション折衝部５０４は、たとえ自機がＥＣＮに対応している場合でも、ＥＣＮをＳＤＰオファーに含めない。つまり、利用アプリケーション折衝部５０４は、基地局４０４，４０６及び自機の双方がＥＣＮに対応している場合のみ、ＥＣＮを含むＳＤＰオファーを作成する。
　利用アプリケーション折衝部５０４が作成したＳＤＰオファーは、無線送信部５００を介して通信相手の端末４００、４０２へ送信される。
　一方、無線受信部５０１でＳＤＰオファーを受け取った端末４００、４０２の利用アプリケーション折衝部５０４は、アプリケーション対応情報取得部５０２が取得した、基地局４０４、４０６のアプリケーション対応情報に基づいてＳＤＰアンサーを作成する。
　例えば、基地局４０４，４０６のアプリケーション対応情報の中にＥＣＮが含まれており、かつ、ＳＤＰオファーにＥＣＮが含まれている場合、利用アプリケーション折衝部５０４は、自機がＥＣＮに対応していれば、ＥＣＮをＳＤＰアンサーに含める（例えば、図３を参照）。一方、基地局４０４，４０６のアプリケーション対応情報の中にＥＣＮが含まれていない場合、利用アプリケーション折衝部５０４は、たとえＳＤＰオファーにＥＣＮが含まれており、かつ自機がＥＣＮに対応している場合でも、ＥＣＮをＳＤＰアンサーには含めない。つまり、利用アプリケーション折衝部５０４は、基地局４０４，４０６及び自機の双方がＥＣＮに対応し、かつ、ＳＤＰオファーにＥＣＮが含まれている場合のみ、ＥＣＮを含むＳＤＰアンサーを作成する。
　利用アプリケーション折衝部５０４が作成したＳＤＰアンサーは、無線送信部５０１を介して通信相手の端末４００、４０２へ送信される。
　このようにして、通信を行う双方の端末４００，４０２がＥＣＮに対応し、かつ、端末４００，４０２の通信経路上に存在する基地局４０４，４０６がＥＣＮに対応しているときに、折衝によってＥＣＮの利用が決定される。換言すると、通信を行う双方の端末４００，４０２でＥＣＮの利用が可能であっても、通信経路上に存在する基地局４０４，４０６がＥＣＮに対応していない場合には、端末４００，４０２間においてＥＣＮ利用の折衝は行われない。これにより、ＥＣＮが利用される場合は、端末４００，４０２間の通信経路上に存在する基地局４０４，４０６もＥＣＮに対応しているので、ＥＣＮによって輻輳を正常に通知することができる。
　［利用アプリケーション情報の通知方法］
　次に、端末４００，４０２間でＳＤＰオファー及びＳＤＰアンサーを用いた折衝によって決定された利用アプリケーションを示す利用アプリケーション情報の通知方法について説明する。
　図８Ａ及び図８Ｂは、利用アプリケーション情報を端末４００，４０２から基地局４０４，４０６に通知する方法の一例を示す。
　図８Ａでは、非特許文献７に記載のRRC connection reconfigurationに係るシグナリングメッセージを用いる。
　具体的には、端末４００、４０２では、無線受信部５００が、アプリケーションを用いた通信のデータ送受信用無線ベアラ(radio bearer)を設定するために、基地局４０４、４０６より送信されるRRCConnectionReconfigurationシグナリングを受信する。RRCConnectionReconfigurationシグナリングを受信すると、利用アプリケーション情報通知部５０５は、利用アプリケーション折衝部５０４で折衝して決定された利用アプリケーション情報の全て又は一部（例えばＥＣＮ利用等）を、RRCConnectionReconfigurationCompleteシグナリングに含めて、無線送信部５０１を介して基地局４０４、４０６へ通知する。
　端末４００、４０２が基地局４０４、４０６よりRRCConnectionReconfigurationシグナリングを受信した時点で、利用アプリケーション折衝部５０４における利用アプリケーションの折衝が完了していない場合、利用アプリケーション情報通知部５０５は、折衝の完了を待ってRRCConnectionReconfigurationCompleteシグナリングを送信する。
　基地局４０４、４０６では、受信部６００が端末４００、４０２から送信されるRRCConnectionReconfigurationCompleteシグナリングを受信すると、利用アプリケーション情報取得部６０４は、RRCConnectionReconfigurationCompleteシグナリングを解析し、利用アプリケーション情報が含まれている場合、当該利用アプリケーション情報を取得する。
　図８Ｂでは、非特許文献９に記載のDedicated bearer activationに係るシグナリングメッセージを用いる。
　まず、ＬＴＥのアプリケーションシグナリング網であるＩＭＳ(IP Multimedia Subsystem)において、ＳＤＰオファー及びＳＤＰアンサーで折衝された情報を取得可能なネットワークノードであるＰ－ＣＳＣＦ(Proxy-Call Session Control Function)が、アプリケーションを用いた通信を行う端末４００、４０２間で折衝された利用アプリケーションを示す利用アプリケーション情報を取得する。
　そして、Ｐ－ＣＳＣＦは、利用アプリケーション情報の全て又は一部（例えばＥＣＮ利用等）を、ＬＴＥのコア網４１２上のネットワークノードであるＰＣＲＦ(Policy and Charging Rules Function)に通知する。また、ＰＣＲＦは、利用アプリケーション情報を、ＬＴＥのコア網４１２上のネットワークノードであるＰ－ＧＷ(Packet Data Network GateWay)に通知する。利用アプリケーション情報の全て又は一部を受け取ったＰ－ＧＷは、利用アプリケーション情報を、アプリケーションを用いた通信のデータ送受信用ベアラを設定するための、Dedicated Bearer Establishment処理のシグナリングに含めて送信する。
　基地局４０４、４０６では、受信部６００がDedicated Bearer Establishment処理のシグナリングを受信すると、利用アプリケーション情報取得部６０４は、Dedicated Bearer Establishment処理のシグナリングを解析し、利用アプリケーション情報が含まれている場合、当該利用アプリケーション情報を取得する。
　このようにして、端末４００，４０２において基地局４０４，４０６のアプリケーション対応情報に基づき通信相手端末との間で折衝されたアプリケーションを示す利用アプリケーション情報は基地局４０４，４０６へ通知される。これにより、基地局４０４，４０６は、例えば、端末４００，４０２において、基地局４０４，４０６が対応するアプリケーションに基づいて折衝が正常に行われたこと確認することができる。また、基地局４０４，４０６は、端末４００，４０２が利用するアプリケーションに基づいてヘッダ圧縮モードを変更することができる（詳細は後述する）。
　なお、端末４００，４０２は、図８ＢのようにDedicated Bearer Establishment処理のシグナリングに利用アプリケーション情報を含める代わりに、利用アプリケーションに応じたＱＣＩ(QoS Class Identifier)を設定し、設定したＱＣＩを通知することにより、利用アプリケーションを通知してもよい。例えば、非特許文献９等に記載の通り、ＶｏＬＴＥのデータ送受信用ベアラのＱＣＩは“１”である。これに対して、ＥＣＮを用いたＶｏＬＴＥ用に新たにＱＣＩを“１．１”と定義し、端末４００，４０２は、“QCI=1.1”をDedicated Bearer Establishment処理のシグナリングに含めて送信してもよい。
　また、図８Ａ及び図８Ｂでは、基地局４０４、４０６が利用アプリケーション情報を取得するためにRRC connection reconfigurationに係るシグナリング、又は、Dedicated Bearer Establishmentのシグナリングを用いる方法を一例として示したが、利用アプリケーション情報の通知方法はこれらに限定されない。例えば、基地局４０４，４０６（利用アプリケーション情報取得部６０４）は、通信を開始した端末４００、４０２が送信するＩＰパケットの中にＥＣＮに対応する情報（ＩＰヘッダのＥＣＮビットが”01”または”10”）が含まれることにより、利用アプリケーションの中にＥＣＮが含まれることを特定してもよい。つまり、利用アプリケーション情報取得部６０４は、ＥＣＮビットの内容を特定することにより、ＥＣＮを含む利用アプリケーション情報を暗黙的に取得する。この場合、利用アプリケーション情報の通知のための図８Ａ及び図８Ｂに示すようなシグナリングは不要となる。
　［圧縮モード決定方法］
　次に、端末４００，４０２の圧縮モード決定部５０６、及び、基地局４０４，４０６の圧縮モード決定部６０５におけるヘッダ圧縮モードの決定方法について説明する。
　圧縮モード決定部５０６及び圧縮モード決定部６０５は、利用アプリケーション情報（つまり、端末４００，４０２間のアプリケーションの折衝結果）に基づいて、利用アプリケーションに適したヘッダ圧縮モードを決定する。
　なお、前述の通り、基地局４０４、４０６から端末４００、４０２へ通知されたアプリケーション対応情報にどのヘッダ圧縮モードを使用するかを示す情報が含まれている場合、圧縮モード決定部５０６及び圧縮モード決定部６０５は、アプリケーション対応情報に含まれるヘッダ圧縮モードに従って適用する圧縮モードを決定する。
　図９は、利用アプリケーションとしてＶｏＬＴＥでのＥＣＮを利用する際のＲｏＨＣの高圧縮モードの一例を示す。
　前述の通り、ＶｏＬＴＥにおいて、有音区間ではＲＴＰシーケンス番号及びＵＤＰチェックサム（ＩＰｖ６の場合）のみが送信され、ＩＰヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダを最大３バイトまで圧縮することが想定されている。
　一方で、ＥＣＮは、ＩＰヘッダのＴｏＳフィールド（ＩＰｖ４の場合）又はTraffic Classフィールド（ＩＰｖ６の場合）の下位２ビットを利用する。
　したがって、ＥＣＮ利用に適したＲｏＨＣの高圧縮モードとしては、ＴｏＳフィールド又はTraffic Classフィールドのみを含むことができる高圧縮モードを用いればよい。
　例えば、非特許文献２によると、高圧縮モードに拡張フラグ（X）を立てて、IPヘッダ拡張部を用意し、このIPヘッダ拡張部に特定のフィールド（ＴｏＳフィールド又はTraffic Classフィールド）を含めることができる。
　そこで、圧縮モード決定部５０６及び圧縮モード決定部６０５は、高圧縮モードの中で、拡張フラグに対応しているモードを選択すればよい。図９の例では、拡張フラグ（X）に対応している高圧縮モードであるＵＯＲ－２モードに拡張フラグを立て（X=1）、ＩＰヘッダ拡張部（ip=1に対応するフィールド）を用意し、IPヘッダ拡張部にTraffic Classフィールドを付け加えている。
　これにより、端末４００，４０２は、基地局４０４，４０６が対応するアプリケーションを考慮して決定されたアプリケーションに適した圧縮モードを決定することができる。また、基地局４０４，４０６は、端末４００，４０２において折衝により決定されたアプリケーションに適したヘッダ圧縮モードを決定することができる。例えば、基地局４０４，４０６は、端末４００，４０２がＥＣＮを利用する場合には、ＥＣＮを用いた輻輳通知に対応するようなＲｏＨＣの圧縮モードを適切に決定することができる。
　なお、ＥＣＮ利用に適したＲｏＨＣの高圧縮モードは、ＵＯＲ－２モードに限定されず、ＥＣＮビットの送信に用いられるフィールド（例えば、ＴｏＳフィールド又はTraffic Classフィールド）を含むことができる高圧縮モードであればよい。例えば、圧縮モード決定部５０６及び圧縮モード決定部６０５は、ＴｏＳフィールド又はTraffic Classフィールドを含むことができる高圧縮モードの中で、圧縮率が最も高いモードを選択してもよい。
　［ハンドオーバ時の利用アプリケーションの制御］
　次に、端末４００，４０２が接続中の基地局４０４，４０６から他の基地局４０４，４０６配下にハンドオーバする場合について説明する。
　図１０Ａ及び図１０Ｂは、端末４００、４０２が他の基地局４０４、４０６配下にハンドオーバする場合の端末４００，４０２の利用アプリケーションに対する制御に関する処理を示す。
　まず、端末４００、４０２の利用アプリケーション制御部５０７は、ハンドオーバ先基地局４０４、４０６(例えば、target eNodeBと呼ばれる)のアプリケーション対応情報に基づいて、ハンドオーバ先基地局４０４，４０６が、端末４００，４０２が現在利用中のアプリケーションに対応しているか否かを示す情報を得る。
　この情報は、ハンドオーバ元基地局４０４、４０６(例えば、serving eNodeBと呼ばれる)からハンドオーバ直前に送信されるRRCConnectionReconfigurationの情報に含まれてもよく、ハンドオーバ先基地局４０４、４０６から送られるSystemInformationBlock又はＭＡＣ　ＣＥの中に含まれてもよい。または、利用アプリケーション制御部５０７は、ハンドオーバ先基地局４０４、４０６が利用するヘッダ圧縮モードが、端末４００、４０２が利用中のアプリケーションに対応しているか否かをすることにより、ハンドオーバ先基地局４０４，４０６が現在利用中のアプリケーションに対応しているか否かを暗黙的に判断してもよい。
　ハンドオーバ元基地局４０４、４０６が端末４００，４０２の利用アプリケーションに対応しており、ハンドオーバ先基地局４０４、４０６も端末４００，４０２の利用アプリケーションに対応していることを検出した場合（図１０Ｂのステップ（ＳＴ）２０１）、端末４００，４０２は、利用アプリケーションを継続して利用すると判断する（図１０ＢのＳＴ２０２）。
　一方、ハンドオーバ元基地局４０４、４０６が端末４００，４０２の利用アプリケーションに対応しているが、ハンドオーバ先基地局４０４、４０６が端末４００，４０２の利用アプリケーションに対応していないことを検出した場合（図１０ＡのＳＴ１０１）、端末４００、４０２は、利用アプリケーション又はアプリケーション機能の一部（例えばＥＣＮ等）の利用を停止すると判断する（図１０ＡのＳＴ１０２）。そして、端末４００，４０２は、利用アプリケーションの機能を停止することを示す利用アプリケーション制御情報を通信相手端末へ通知する（図１０ＡのＳＴ１０３）。通信相手端末は、利用アプリケーションの機能を停止することを示す利用アプリケーション制御情報を受け取ると、ＥＣＮの利用を停止する。
　なお、利用アプリケーション機能停止の通知方法として、例えば、ＥＣＮの利用を停止する場合、端末４００，４０２は、これまで使用していたＥＣＮビットを、ＥＣＮ非対応を示す“00”に設定して送信してもよい。ＥＣＮビットが“00”であるＩＰパケットを受け取った通信相手の端末４００，４０２の利用アプリケーション制御部５０７、及び、通信相手側の基地局４０４，４０６の利用アプリケーション制御情報取得部６０６は、ＥＣＮの利用を停止する。
　また、端末４００、４０２の利用アプリケーション制御部５０７は、ＥＣＮビットを”00”として送信する前に、通信相手の端末４００、４０２に対してＳＤＰオファーを再度送信し、ＳＤＰオファー及びＳＤＰアンサーによってＥＣＮの停止を折衝してもよい。
　次に、端末４００，４０２の利用アプリケーションの全て又は一部（例えば、ＥＣＮ等）が一度停止した状態で、端末４００，４０２が再びハンドオーバし、ハンドオーバ先基地局４０４，４０６が当該利用アプリケーションに対応していると判断した場合の動作について説明する。
　この場合、端末４００，４０２は、ハンドオーバ先基地局４０４、４０６において停止中の利用アプリケーションを再開すると判断する（図１０ＢのＳＴ２０２）。
　そして、端末４００，４０２は、通信開始時に利用していたアプリケーションを再開することを通信相手の端末４００，４０２に照会する（図１０ＢのＳＴ２０３）。照会方法としては、例えば、ＥＣＮの場合、端末４００，４０２は、ＥＣＮビットを、ＥＮＣ対応を示す“01”又は“10”に設定して送信してもよい。ＥＣＮビットが“01”又は“10”であるＩＰパケットを受け取った通信相手の端末４００、４０２の利用アプリケーション制御部５０７は、ＥＣＮの再開を行っても問題無い場合、ＥＣＮビットを、ＥＣＮ対応を示す“01”又は“10”に設定してＩＰパケットを送り返す。
　なお、ＥＣＮの再開を行っても問題無い場合とは、すなわち、ＥＣＮビットが“01”又は“10”となったＩＰパケットを受け取った通信相手の端末４００、４０２側で現在接続している基地局４０４、４０６もＥＣＮに対応している場合である。
　一方、ＥＣＮビットが“01”又は“10”となったＩＰパケットを受け取った通信相手の端末４００、４０２側で現在接続している基地局４０４、４０６がＥＣＮに対応していない場合、すなわち、ＥＣＮの再開を行うと問題が生じる場合、通信相手の端末４００，４０２の利用アプリケーション制御部５０７は、ＥＣＮビットを、非対応を示す”00”に設定してＩＰパケットを送り返す。
　なお、ＥＣＮの再開が端末４００、４０２間で折衝された場合、基地局４０４、４０６の利用アプリケーション制御情報取得部６０６は、ＥＣＮビットが“01”又は“10”であるＩＰパケットを受け取ることにより、ＥＣＮの再開情報を取得する。これにより、基地局４０４，４０６は、停止したＥＣＮの機能を再開する。
　また、端末４００、４０２の利用アプリケーション制御部５０７は、ＥＣＮのビットを“01”又は“10”として送信する前に、通信相手の端末４００、４０２に対してＳＤＰオファーを再度送信し、ＳＤＰオファー及びＳＤＰアンサーによってＥＣＮの再開を折衝してもよい。
　このようにして、端末４００，４０２は、ハンドオーバ先基地局４０４，４０６が対応するアプリケーションに基づいて、利用するアプリケーションの継続、停止又は再開を制御する。これにより、端末４００，４０２は、ハンドオーバの度にＳＤＰオファー及びＳＤＰアンサーを用いることなく、通信相手端末との間で確立されたデータパス上で当該アプリケーションの利用を折衝することができる。
　［本実施の形態の効果］
　以上のように、本実施の形態では、端末４００，４０２は、通信相手端末との通信経路上に存在する基地局４０４，４０６が対応するアプリケーションを示すアプリケーション対応情報を取得し、自機が対応するアプリケーションのうち、基地局４０４，４０６のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を通信相手端末と折衝し、折衝されたアプリケーションに基づいてヘッダ圧縮モードを決定する。
　これにより、ＥＣＮを用いた輻輳通知を行う端末４００，４０２間の通信経路上に存在する基地局４０４，４０６の中にＥＣＮに対応していない基地局が含まれる場合には、端末４００，４０２間でＥＣＮの利用について折衝しない。よって、端末４００，４０２間の通信経路上に存在する基地局が、ＩＰヘッダを省略するような高圧縮モードを適用してしまい、ＩＰヘッダ内のＥＣＮビットが送信されなくなることを防ぐことができる。
　また、端末４００，４０２及び基地局４０４，４０６は、折衝されたアプリケーション（例えば、ＥＣＮ）に基づいてヘッダ圧縮モードを決定する。これにより、ＲｏＨＣの高圧縮モードが適用される場合でも、ＥＣＮビットの通知を考慮した高圧縮モード（例えば、図９を参照）の使用が可能となる。換言すると、ＥＣＮを用いた輻輳通知に関係無く、ＲｏＨＣの圧縮モードが低圧縮モードに変更されてしまうことを防ぐことができる。
　このように、本実施の形態によれば、ＥＣＮをサポートする環境において高圧縮モードを適切に適用することができる。また、高圧縮モードにおいてＥＣＮによって輻輳を正常に通知することができるので、輻輳通知が頻繁に発生することを防ぎ、無線リソースの無駄な消費を抑えることができる。
　［他の実施の形態］
　なお、端末４００，４０２が利用するアプリケーションは、ＥＣＮに限定されず、他のアプリケーションを利用してもよい。
　例えば、非特許文献５及び非特許文献１０に記載のＭＭＣＭＨ（Multi-stream Multiparty Conferencing for Multimedia Telephony Service for MTSI：マルチストリーム対応端末)に本開示の方式を適用しても、効率的なヘッダ圧縮モードを利用することができる。図１１は、ＶｏＬＴＥでのＭＭＣＭＨ利用に適したＲｏＨＣの高圧縮モードの例を示す。ＭＭＣＭＨでは、１セッション内の複数のＶｏＬＴＥフロー（ストリーム）を区別できればよい。従って、ＭＭＣＭＨ利用時には、非特許文献２に記載のＣＩＤ(Context ID)を含むような高圧縮モードを用いればよい。例えば、基地局４０４，４０６（圧縮モード決定部６０５）は、ＣＩＤを送信するフィールドを有するヘッダ圧縮モードのうち圧縮率が最も高い圧縮モードを選択してもよい。なお、ＣＩＤを用いるにあたり、使用されるＶｏＬＴＥフロー数に従い、ＣＩＤの上限(maxCID)を、非特許文献１及び非特許文献７に記載の方法で、端末４００、４０２と基地局４０４、４０６の間で折衝してもよい。
　また、基地局４０４、４０６のアプリケーション対応情報通知部６０２から、サポートしているアプリケーションの情報だけでなく、無線品質の状態などにより、サポートできないアプリケーションの情報を通知しても良い。例えば、無線アクセス網４０８、４１０の混雑などにより、音声のみの通話（ＶｏＬＴＥ）に対する無線リソースを割り当てる事は可能だが、テレビ電話等のビデオに対する無線リソースを割り当てる事が難しい場合、基地局４０４，４０６は、図７Ａ又は図７Ｂに示す方法などにより、ビデオをサポートしていない事、又はビデオを一時的にサポートできない事を端末４００、４０２に通知しても良い。この通知を受け取った端末４００、４０２の利用アプリケーション折衝部５０４は、通信を開始する際、ＳＤＰオファー又はアンサーにｖｉｄｅｏに関するメディアライン(media line)を含めない事により、テレビ電話ではなく音声のみの通話を折衝する。なお、端末４００、４０２のアプリケーション対応情報取得部５０２が、基地局４０４、４０６からビデオをサポートしていない事、又はビデオを一時的にサポートできない事を取得した際、端末４００，４０２のユーザにビデオが使えない事を通知するため、画面などにビデオが使えない事を示す情報を表示しても良い。また、通信開始時にはテレビ電話を利用していたが、ハンドオーバ先の基地局４０４，４０６でビデオをサポートしていない、又はビデオを一時的にサポートできないとなった場合、端末４００、４０２の利用アプリケーション制御部５０７は、非特許文献９に記載の、UE requested bearer resource modificationなどを用いて、ビデオ用ベアラに割り当てられているリソースを開放するなどの方法で、ビデオ利用を停止する。ビデオ利用の再開に関しても同様に、ビデオ用ベアラに再度リソースを割り当てる方法が適応できる。また、ベアラのリソースを開放、再割当の方法ではなく、通信相手端末４００、４０２との間でＳＤＰオファー及びＳＤＰアンサーを交換し、再折衝する事により、ビデオの停止及び再開を行っても良い。ビデオの停止、再開の際、端末４００、４０２のユーザに伝えるため、画面に表示する、又は音を鳴らすなどの方法を用いても良い。
　また、上記実施の形態では、ＬＴＥネットワークにおいて、アプリケーション及びアプリケーションの特性に対し、効率的なヘッダ圧縮方式を選択する方法について記述したが、本開示の方式が適用されるのはＬＴＥネットワークに限るものではない。例えば、非特許文献１１に記載のような、次世代ネットワークに本開示の方式を適応してもよい。この場合、ＬＴＥネットワークの場合のベアラは、次世代ネットワークのスライスであってもよい。
　また、上記実施の形態に限定されず、種々変更して実施することが可能である。
　また、上記実施の形態では、本開示の一態様をハードウェアで構成する場合を例にとって説明したが、本開示はハードウェアとの連携においてソフトウェアで実現することも可能である。
　また、上記実施の形態の説明に用いた各機能ブロックは、典型的には、入力端子および出力端子を有する集積回路であるＬＳＩとして実現される。集積回路は、上記実施の形態の説明に用いた各機能ブロックを制御し、入力端子と出力端子を備えてもよい。これらは個別に１チップ化されてもよいし、一部または全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
　また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
　さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　本開示の端末は、通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得する取得部と、自機が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝する折衝部と、前記アプリケーションの折衝結果に基づいて圧縮モードを決定する圧縮モード決定部と、を具備する。
　本開示の端末において、自機が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションを示す第２のアプリケーション対応情報を前記基地局へ通知する第１通知部、をさらに具備する。
　本開示の端末において、前記折衝部によって利用が決定されたアプリケーションを示す利用アプリケーション情報を前記基地局へ通知する第２通知部、をさらに具備する。
　本開示の端末において、前記端末がハンドオーバする場合、ハンドオーバ先基地局が対応するアプリケーションの情報に基づいて、利用中のアプリケーションの停止又は継続を判断する制御部、をさらに具備する。
　本開示の端末において、前記制御部は、前記アプリケーションを停止した後、前記端末が当該アプリケーションに対応する基地局へハンドオーバする場合、当該アプリケーションの利用を再開する。
　本開示の端末において、前記アプリケーションは、ＥＣＮ（Explicit Congestion Notification）であり、前記圧縮モード決定部は、ＥＣＮの通知ビットを送信するフィールドを有するモードのうち圧縮率が最も高いモードを選択する。
　本開示の端末において、前記ＥＣＮの通知ビットを送信するフィールドは、ＴｏＳ（Type of Service）フィールド又はTraffic Classフィールドである。
　本開示の端末において、前記アプリケーションは、ＭＭＣＭＨ（Multi-stream Multiparty Conferencing for Multimedia Telephony Service for MTSI）であり、前記圧縮モード決定部は、ＣＩＤ(Context ID)を送信するフィールドを有するモードのうち圧縮率が最も高いモードを選択する。
　本開示の基地局は、自機が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知する通知部と、前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得するアプリケーション情報取得部と、前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する圧縮モード決定部と、を具備する。
　本開示の通信方法は、端末と通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得し、前記端末が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝し、前記アプリケーションの折衝結果に基づいて圧縮モードを決定する。
　本開示の通信方法は、基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知し、前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得し、前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する。
　本開示は、通信に使用されるアプリケーション及びアプリケーションの特性に対して効率的なヘッダ圧縮方式を選択する通信システム等に好適である。
　４００，４０２　端末
　４０４，４０６　基地局
　４０８，４１０　無線アクセス網
　４１２　コア網
　５００　無線受信部
　５０１　無線送信部
　５０２，６０３　アプリケーション対応情報取得部
　５０３，６０２　アプリケーション対応情報通知部
　５０４　利用アプリケーション折衝部
　５０５　利用アプリケーション情報通知部
　５０６，６０５　圧縮モード決定部
　５０７　利用アプリケーション制御部
　６００　受信部
　６０１　送信部
　６０４　利用アプリケーション情報取得部
　６０６　利用アプリケーション制御情報取得部

Claims (11)

  1. 　通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得する取得部と、
    　自機が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝する折衝部と、
    　前記アプリケーションの折衝結果に基づいて圧縮モードを決定する圧縮モード決定部と、
    　を具備する端末。
  2. 　自機が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションを示す第２のアプリケーション対応情報を前記基地局へ通知する第１通知部、をさらに具備する、
    　請求項１に記載の端末。
  3. 　前記折衝部によって利用が決定されたアプリケーションを示す利用アプリケーション情報を前記基地局へ通知する第２通知部、をさらに具備する、
    　請求項１に記載の端末。
  4. 　前記端末がハンドオーバする場合、ハンドオーバ先基地局が対応するアプリケーションの情報に基づいて、利用中のアプリケーションの停止又は継続を判断する制御部、をさらに具備する、
    　請求項１に記載の端末。
  5. 　前記制御部は、前記アプリケーションを停止した後、前記端末が当該アプリケーションに対応する基地局へハンドオーバする場合、当該アプリケーションの利用を再開する、
    　請求項４に記載の端末。
  6. 　前記アプリケーションは、ＥＣＮ（Explicit Congestion Notification）であり、
    　前記圧縮モード決定部は、ＥＣＮの通知ビットを送信するフィールドを有するモードのうち圧縮率が最も高いモードを選択する、
    　請求項１に記載の端末。
  7. 　前記ＥＣＮの通知ビットを送信するフィールドは、ＴｏＳ（Type of Service）フィールド又はTraffic Classフィールドである、
    　請求項６に記載の端末。
  8. 　前記アプリケーションは、ＭＭＣＭＨ（Multi-stream Multiparty Conferencing for Multimedia Telephony Service for MTSI）であり、
    　前記圧縮モード決定部は、ＣＩＤ(Context ID)を送信するフィールドを有するモードのうち圧縮率が最も高いモードを選択する、
    　請求項１に記載の端末。
  9. 　自機が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知する通知部と、
    　前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得するアプリケーション情報取得部と、
    　前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する圧縮モード決定部と、
    　を具備する基地局。
  10. 　端末と通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得し、
    　前記端末が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝し、
    　前記アプリケーションの折衝結果に基づいて圧縮モードを決定する、
    　通信方法。
  11. 　基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知し、
    　前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得し、
    　前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する、
    　通信方法。
PCT/JP2017/019456 2016-08-12 2017-05-25 端末、基地局及び通信方法 WO2018029939A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2018533431A JP6847115B2 (ja) 2016-08-12 2017-05-25 端末、基地局及び通信方法
US16/224,492 US10716029B2 (en) 2016-08-12 2018-12-18 Terminal, base station, and communication method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016158839 2016-08-12
JP2016-158839 2016-08-12

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/224,492 Continuation US10716029B2 (en) 2016-08-12 2018-12-18 Terminal, base station, and communication method

Publications (1)

Publication Number Publication Date
WO2018029939A1 true WO2018029939A1 (ja) 2018-02-15

Family

ID=61162104

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/019456 WO2018029939A1 (ja) 2016-08-12 2017-05-25 端末、基地局及び通信方法

Country Status (3)

Country Link
US (1) US10716029B2 (ja)
JP (1) JP6847115B2 (ja)
WO (1) WO2018029939A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180096370A (ko) * 2017-02-21 2018-08-29 삼성전자주식회사 무선 통신 시스템에서 암호화 파라미터 값을 결정하기 위한 장치 및 방법
CN114710781A (zh) * 2020-12-16 2022-07-05 华为技术有限公司 一种终端识别方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001211443A (ja) * 2000-01-27 2001-08-03 Mega Chips Corp 情報配信システム
JP2002534874A (ja) * 1998-12-23 2002-10-15 エリクソン インコーポレイテッド インターネットプロトコル準拠性能を持った柔軟性を有する通信システム
JP2006237940A (ja) * 2005-02-24 2006-09-07 Kyocera Corp パケット通信装置、パケット通信システム、パケット通信方法、及びパケット通信プログラム
JP2008166871A (ja) * 2006-12-26 2008-07-17 Fujitsu Ltd データ転送システム、接近通知システム、およびデータ転送方法
US20140341015A1 (en) * 2011-12-01 2014-11-20 Telefonaktiebolaget, L M Ericsson (PUBL) Reduction of packet header compression overhead due to high ecn rate
JP2015507854A (ja) * 2011-09-09 2015-03-12 インターデイジタル パテント ホールディングス インコーポレイテッド ローカライズドアプリケーションにアクセスするための方法および装置

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3799326B2 (ja) * 2002-12-02 2006-07-19 Ｎｅｃインフロンティア株式会社 パケット送信方式及びパケット受信方式
US8339963B2 (en) * 2003-08-27 2012-12-25 Rockstar Consortium Us Lp Technique for end-to-end admission control of real-time packet flows
CN100477851C (zh) * 2005-01-05 2009-04-08 国际商业机器公司 在无线局域网的两种通信模式之间进行切换的方法和系统
WO2006129600A1 (ja) * 2005-06-02 2006-12-07 Sharp Kabushiki Kaisha 通信システム及び通信方法
CN101035375A (zh) * 2007-02-02 2007-09-12 华为技术有限公司 一种自适应通信系统、终端、方法及接入点
KR101376816B1 (ko) * 2007-04-24 2014-04-01 엘지전자 주식회사 무선통신 시스템에서 제어신호 전송방법
JP2008306419A (ja) * 2007-06-07 2008-12-18 Sony Corp 送信装置及び方法、並びにプログラム
WO2010124471A1 (zh) * 2009-04-30 2010-11-04 华为技术有限公司 一种数据传输的方法、装置
US8427949B2 (en) * 2009-08-07 2013-04-23 Future Wei Technologies, Inc. System and method for adapting a source rate
CN102026320B (zh) * 2009-09-22 2013-10-09 华为终端有限公司 网络切换方法、系统及设备
US8416690B2 (en) * 2010-01-11 2013-04-09 Research In Motion Limited Explicit congestion notification based rate adaptation using binary marking in communication systems
CN102137451A (zh) * 2010-01-22 2011-07-27 中兴通讯股份有限公司 一种终端与基站协商应用支持能力的系统及方法
CN102158896B (zh) * 2010-02-12 2014-01-01 华为技术有限公司 处理本地链路拥塞的方法和装置
US20130029716A1 (en) * 2010-04-12 2013-01-31 Lg Electronics Inc. Apparatus and method for performing group-based m2m communication
EP2464180A1 (en) * 2010-12-07 2012-06-13 LG Electronics Inc. Apparatus and method for updating a location in a wireless access system
US8843165B2 (en) * 2010-12-08 2014-09-23 At&T Intellectual Property I, L.P. Enhanced delivery of messaging data traffic
WO2012110301A1 (en) * 2011-02-14 2012-08-23 Nokia Siemens Networks Oy Different application of compressed mode
US9392624B2 (en) * 2011-03-02 2016-07-12 Zte Corporation Methods and apparatus for radio configuration indication
US9554330B2 (en) * 2011-11-25 2017-01-24 Nec Communication Systems, Ltd. Wireless communication device
US20130194937A1 (en) * 2012-01-31 2013-08-01 Alcatel-Lucent Usa Inc. Method and apparatus for providing intelligent codec rate adaptation for wireless users
US10574417B2 (en) * 2013-03-04 2020-02-25 Qualcomm Incorporated Method and apparatus for MTC device association schemes
US20150201411A1 (en) * 2014-01-10 2015-07-16 Qualcomm Incorporated Handling invalid configurations for enhanced uplink in cell_fach state
US20150312319A1 (en) * 2014-04-29 2015-10-29 Qualcomm Incorporated Access point with limited range
WO2016004599A1 (zh) * 2014-07-10 2016-01-14 华为技术有限公司 一种数据的传输方法、系统及相关装置
US10341466B2 (en) * 2014-11-14 2019-07-02 Qualcomm Incorporated Evolved data compression scheme signaling
US10470090B2 (en) * 2014-11-14 2019-11-05 Qualcomm Incorporated Data compression techniques for handover and radio link failure recovery
CN106301679B (zh) * 2015-06-10 2020-10-23 华为技术有限公司 业务速率的调整方法和装置
CA3016848C (en) * 2016-03-28 2024-01-09 Panasonic Intellectual Property Corporation Of America User equipment, base station and codec mode switching method
US11171999B2 (en) * 2016-07-21 2021-11-09 Qualcomm Incorporated Methods and apparatus for use of compact concurrent codecs in multimedia communications
US10674351B2 (en) * 2017-06-16 2020-06-02 Qualcomm Incorporated Antenna port compatibility signaling

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002534874A (ja) * 1998-12-23 2002-10-15 エリクソン インコーポレイテッド インターネットプロトコル準拠性能を持った柔軟性を有する通信システム
JP2001211443A (ja) * 2000-01-27 2001-08-03 Mega Chips Corp 情報配信システム
JP2006237940A (ja) * 2005-02-24 2006-09-07 Kyocera Corp パケット通信装置、パケット通信システム、パケット通信方法、及びパケット通信プログラム
JP2008166871A (ja) * 2006-12-26 2008-07-17 Fujitsu Ltd データ転送システム、接近通知システム、およびデータ転送方法
JP2015507854A (ja) * 2011-09-09 2015-03-12 インターデイジタル パテント ホールディングス インコーポレイテッド ローカライズドアプリケーションにアクセスするための方法および装置
US20140341015A1 (en) * 2011-12-01 2014-11-20 Telefonaktiebolaget, L M Ericsson (PUBL) Reduction of packet header compression overhead due to high ecn rate

Also Published As

Publication number Publication date
JPWO2018029939A1 (ja) 2019-06-06
JP6847115B2 (ja) 2021-03-24
US10716029B2 (en) 2020-07-14
US20190124550A1 (en) 2019-04-25

Similar Documents

Publication Publication Date Title
USRE49636E1 (en) Method and apparatus of improving quality of calls in mobile communication system
US9088917B1 (en) Efficient handover of media communications in heterogeneous IP networks
US7613147B2 (en) Packet-based conversational service for a multimedia session in a mobile communications system
US8218530B2 (en) Seamless handoff between access networks with saved session information
WO2011050525A1 (zh) 一种将视频通话从ps域切换到cs域的方法和装置
US9801092B2 (en) Method and apparatus for controlling header compression function of terminal in a communication system
US9332094B2 (en) Communication system and method
US11909775B2 (en) Methods and apparatuses for enhancement to IP multimedia subsystem
US20040120357A1 (en) On-demand header compression
US10716029B2 (en) Terminal, base station, and communication method
US10560878B2 (en) Communication system, terminal, and communication control method
CN112753240B (zh) 终端装置、基站装置以及方法
JP2023169450A (ja) 端末装置、基地局装置、および方法
KR100882903B1 (ko) 브이 오 아이피 네트워크의 호 설정 시스템 및 호 설정방법
JP4912833B2 (ja) 無線通信システムおよび移動端末
WO2020166310A1 (ja) 端末装置、および、方法
WO2020195529A1 (ja) 端末装置、基地局装置、および、方法
WO2019104523A1 (zh) 语音会话建立方法、装置、设备及存储介质
JP2020137084A (ja) 端末装置、基地局装置、方法、および、集積回路
JP2020156028A (ja) 端末装置、基地局装置、方法、および、集積回路
JP2008245103A (ja) 基地局および通信制御方法

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2018533431

Country of ref document: JP

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

Ref document number: 17839014

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17839014

Country of ref document: EP

Kind code of ref document: A1