WO2011135800A1 - 通信装置、ネットワークノード並びに通信サーバ - Google Patents

通信装置、ネットワークノード並びに通信サーバ Download PDF

Info

Publication number
WO2011135800A1
WO2011135800A1 PCT/JP2011/002264 JP2011002264W WO2011135800A1 WO 2011135800 A1 WO2011135800 A1 WO 2011135800A1 JP 2011002264 W JP2011002264 W JP 2011002264W WO 2011135800 A1 WO2011135800 A1 WO 2011135800A1
Authority
WO
WIPO (PCT)
Prior art keywords
bearer
traffic
bandwidth
mtc
mtc device
Prior art date
Application number
PCT/JP2011/002264
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 JP2012512648A priority Critical patent/JP5718322B2/ja
Priority to US13/643,637 priority patent/US9143461B2/en
Publication of WO2011135800A1 publication Critical patent/WO2011135800A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
    • H04L47/748—Negotiation of resources, e.g. modification of a request
    • 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/245—Traffic characterised by specific attributes, e.g. priority or QoS using preemption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
    • H04L47/745—Reaction in network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/824—Applicable to portable or mobile terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Definitions

  • the present invention relates to a communication technique in a packet-switched data communication network. Specifically, the present invention relates to a communication device that belongs to a certain group and has a bandwidth restriction related to a group bandwidth upper limit value, a network node that constitutes a network, and a communication server.
  • GSM Global System for Mobile Communications
  • GPRS General Packet Radio Service
  • UMTS Universal Mobile Telecommunications System
  • LTE Long Term Evolution
  • Current cellular networks provide not only rudimentary voice calling services, but also provide short text message transmission and access to the global Internet.
  • M2M machine-to-machine
  • 3GPP Third Generation Generation Partnership Project
  • M2M machine-to-machine
  • M2M communication is a communication paradigm different from human-to-human (H2H) communication.
  • M2M communication differs in communication scenarios and communication models.
  • Most of the machine type communication scenarios involve communication between a single or multiple machine type communication (MTC) device and a single MTC server.
  • MTC machine type communication
  • the following a) to g) are examples of scenarios in which the MTC device communicates with the MTC server.
  • Route tracking tracked by server c) industry monitoring property, d) weather sensor to update weather information to server, e) food sensor to update food status information to server, f) power outage and power
  • a smart meter in the home that updates information related to consumption to the MTC server, g) a surveillance camera that updates detection information of intruders to the MTC server.
  • MTC communication scenario such as communication between MTC devices.
  • M2M communication different from human-to-human are as follows. a) Operates without human intervention or decision processing, b) has different communication traffic types such as delay tolerance and very low data applications, etc. c) only mobile exists, server for data acquisition D) have different communication models such as polling models, general mobile types, etc.
  • the number of MTC devices connected to the 3GPP core is much higher than the traditional user equipment (UE) connected to 3GPP, and it is essential to have network optimization targeting the unique characteristics of machine type communication It is. As a result, network operators can greatly reduce operating costs and provide an attractive charging model associated with MTC devices.
  • UE user equipment
  • Non-Patent Document 1 Standardization in the 3GPP SA1 (Service Aspects 1) and SA 2 (Service Aspects 2) working groups to plan the service and architecture requirements to provide network optimization specifically implemented with respect to the unique characteristics of MTC devices Has been done.
  • the service requirements and network optimization related to the MTC device are disclosed in Non-Patent Document 1 below, for example.
  • Many of the service requirements related to MTC disclosed in Non-Patent Document 1 are aimed at optimizing a network for MTC communication or improving the network.
  • Non-Patent Document 1 discloses a service requirement that an upper bandwidth limit is imposed on a group of MTC devices belonging to a single subscriber and communicating with an MTC server.
  • G-AMBR group-wide maximum bit rate
  • all parameters related to bandwidth are expressed in units of bits / second.
  • G-AMBR can be independently assigned for uplink and / or downlink.
  • the uplink G-AMBR is described as UL-G-AMBR
  • the downlink G-AMBR is described as DL-G-AMBR.
  • U-plane user plane
  • only UL-G-AMBR may be applied.
  • only DL-G-AMBR may be applied.
  • G-AMBR When G-AMBR is applied, the total bandwidth related to user plane traffic performed by a large number of MTC devices belonging to the group cannot exceed G-AMBR at any time.
  • traffic shaping is performed at an implementation point (a point for checking bandwidth usage).
  • P-GW packet data network gateway
  • the traffic enforcement point becomes P-GW.
  • the main motivation for allocating this G-AMBR is to set a G-AMBR with a value smaller than the total bandwidth required when all MTC devices in the group use the core network simultaneously. .
  • G-AMBR is usually a static value assigned by home subscription server (HSS), or is statically stored in P-GW, or policy control and charging related function (PCRF) to P-GW are provided in a static manner.
  • HSS home subscription server
  • PCRF policy control and charging related function
  • the G-AMBR may be a dynamic value that can be dynamically managed by the PCRF.
  • G-AMBR bandwidth currently used among multiple MTC devices in the group has reached G-AMBR, and another MTC device in the group will transmit user plane traffic. Problems occur.
  • the free bandwidth available in the group (referred to here as AvGrBW) is (G-AMBR)-(current total amount of bandwidth or bit rate for MTC devices in the group transmitting U-plane traffic) equal.
  • AvGrBW can be expressed in bits / second.
  • Non-Patent Document 2 As outlined in Non-Patent Document 2, according to the operation in a normal UE, the quality of service parameter associated with the default bearer during the initial attach process is the non-access stratum (Non-Access Stratum). : NAS) message (Attach Accept message) is notified from the mobility management entity (MME) to the UE.
  • MME mobility management entity
  • Attach Accept message is notified from the mobility management entity (MME) to the UE.
  • MME mobility management entity
  • the bearer modification process (Bearer Modification procedure) is used. Then, the change of the bearer context is notified to the UE.
  • Non-Patent Document 2 describes definitions of a connection mode and an idle mode.
  • the bearer change process can be triggered in most cases by the P-GW and may also be triggered by the MME. From the above description of normal UE processing, the UE needs to know the bearer context in advance, so that it can transmit uplink U-plane traffic with appropriate characteristics, and downlink U-plane traffic. It will be clear that you will be able to receive Moreover, it does not violate the QoS model of resource management or 3GPP evolved packet system (EPS). For example, if the network assigns a certain bandwidth related parameter to a bearer (eg, dedicated bearer), the UE must adjust the transmission rate of U-plane traffic accordingly. .
  • EPS evolved packet system
  • the network is concerned with the maximum bandwidth (UE-AMBR) for all non-GBR (Guaranteed BitRate) flows associated with the UE, or the access point name (APN) of the UE.
  • UE-AMBR maximum bandwidth
  • APN-AMBR access point name
  • the UE When allocating maximum bandwidth (APN-AMBR) for a non-GBR flow, the UE must ensure that the bandwidth associated with that flow does not exceed the upper limit imposed by the network.
  • An important advantage of knowing bearer characteristics in advance is that U-plane traffic transmission can be started quickly when the UE changes state from idle mode to connected mode. This eliminates the need for the UE to wait for time to know the bearer context before sending U-plane traffic.
  • the QoS parameters related to the bearer are, for example, QCI (quality class indication), ARP (allocation and retention priority), MBR (maximum bit rate), GBR (guaranteed bit rate), and the like.
  • QCI quality class indication
  • ARP allocation and retention priority
  • MBR maximum bit rate
  • GBR guaranteed bit rate
  • group QoS parameters for non-GBR bearers such as UE-AMBR and APN-AMBR are also allocated. Detailed descriptions and definitions of these QoS parameters are clearly disclosed in Non-Patent Document 2.
  • PDN packet data network
  • a minimum required default bearer is created.
  • the default bearer is assigned a minimum QoS parameter (a QCI value that requires a minimum QoS process).
  • This bearer is usually a non-GBR bearer.
  • the dedicated bearer is normally generated by a bearer generation request process (P-GW initiated create bearer request procedure) started by the P-GW.
  • the dedicated bearer may be a GBR bearer or a non-GBR bearer.
  • the network guarantees the bandwidth for the dedicated bearer, but the GBR of the dedicated bearer can be changed at any time when resources are not available.
  • the change of the dedicated bearer hardly occurs, and the dedicated bearer change is notified to the UE in advance.
  • the UE UE-AMBR and APN-AMBR of the UE are hardly changed, and this information can be notified to the UE by using the bearer change process without QoS change outlined in Non-Patent Document 2. It is assumed. For example, when the UE is in the idle mode, the change of the bearer context is notified by the first paging, and thereby the UE executes a service request process.
  • the modified bearer context is passed to the UE.
  • the network needs little to worry about resource management and bearer changes rarely occur, so the cost of paging and signaling associated with paging is not very high. For example, it is unlikely that UE-AMBR, APN-AMBR, and GBR for dedicated bearers will be changed.
  • special technologies related to the upper limit of group bandwidth and efficient resource management accommodation M2M communication that requires connection of a very large number of MTC devices
  • the network sends more bearer change messages.
  • Patent Document 1 discloses a method of reallocating bandwidth from the first device to the second device when the bandwidth is not used in the first device. Here, it is considered that the device is performing group communication. Patent Document 1 discloses a method for realizing efficient use of bandwidth by transferring a bandwidth that is not used in a certain device to another device.
  • Patent Document 2 discloses a method for realizing a communication mechanism of a group communication model that allows only a single device in a group to perform communication.
  • the priority mechanism is covered by the method in which priority is used in the initial access control.
  • the interrupt priority for acquiring a device having a higher priority than the service is also covered.
  • Patent Document 3 discloses a method in which a communication priority is assigned to a terminal by an authentication server at the time of attachment. Further, it is considered that the assigned communication priority is notified from the authentication server to the router. Further, it is considered that a communication priority is added to a packet transmitted from the terminal. When the router finds a packet to which this communication priority is added, it performs processing in a special way. Furthermore, the router performs access control for a terminal with a high priority based on the communication priority.
  • Patent Document 4 discloses a method for appropriately addressing group devices.
  • the transmission network includes a flexible topology for defining forwarding elements internally.
  • Each forwarding element includes a port group belonging to the transmission network and having a plurality of geographically distributed ports.
  • Point-to-multipoint connectivity is defined between ports of a port group.
  • the identifier represents a port group as a single element corresponding to an internal and / or external element for protocol exchange.
  • 3GPP TS 22.368 V2.0.0 “Service Requirements for Machine Type Communications”, March 2010
  • 3GPP TS 23.401 V9.3.0 “3rd Generation Generation Partnership Project; Technical Technical Specification Group Service Services and System Aspects; General Packet Packet Radio Service (GPRS) enhancements for Universal Evolved Universal Terrestrial Radio Access
  • GPRS General Packet Packet Radio Service
  • G-AMBR group bandwidth cap
  • the MTC devices in that group have real-time traffic, high bandwidth traffic, and high priority U-plane traffic as data to be transmitted.
  • AvGrBW is not sufficient to transmit MTC device wideband and non-delay-tolerant traffic (eg high priority real-time video capture information).
  • G-AMBR is used as a group QoS parameter for an MTC device under a group model
  • the MTC device needs to know the AvGrBW for that group. If the MTC device does not know this value, the uplink U-plane traffic transmission cannot be performed correctly.
  • the U-plane traffic transmission rate needs to be reliably smaller than AvGrBW.
  • the MTC device has delay-resistant traffic that may be subjected to rate control (for example, data traffic that can be transmitted at an arbitrary transmission rate)
  • the MTC device knows AvGrBW and uses the application. It is necessary to be able to change the traffic rate according to AvGrBW.
  • the MTC devices 103, 104, 105, and 106 join a group, and in most cases, communicate with the MTC server 102 through the core network (3GPP EPC) 100.
  • the P-GW 101 monitors the U-plane uplink traffic rate to understand the bandwidth associated with the MTC device 106. To do.
  • uplink U-plane traffic from MTC device 106 is shown as message 110.
  • AvGrBW which is (UL-G-AMBR) ⁇ (uplink u-plane traffic rate from MTC device 106)
  • bearer modification processing without bearer update (bearer modification modification procedure without bearer protocol QoS update )
  • the bearer change process that does not update the bearer QoS generally changes the traffic flow template (TFT) and / or the APN-AMBR as disclosed in Non-Patent Document 2. Used when Signaling related to the bearer change process transmitted towards the MTC devices 103, 104, 105 is indicated by signaling messages 107, 108, 109, respectively.
  • the bearer change signaling to the MTC devices 104, 105 is useless signaling.
  • the addition of bearer change signaling as indicated by signaling messages 108, 109 is undesirable because of the signaling overhead. If there are many MTC devices in the group that do not require information transmitted by bearer change signaling for transmitting AvGrBW, the bearer change signaling will waste core network resources.
  • the MTC device shown in FIG. 1 has low power, and unnecessarily activating MTCs 104 and 105 to update AvGrBW wastes the power of MTC devices with limited power supply. become.
  • the MTC device 103 has uplink U-plane traffic to be transmitted.
  • the traffic of the MTC device 103 is real time, high priority, wide bandwidth, cannot be delayed, and the rate cannot be controlled.
  • AvGrBW notified to the MTC device 103 cannot support the bit rate required by the MTC device 103. Since AvGrBW is not sufficient, high priority, real time, high bandwidth traffic will not reach the MTC server 102.
  • the MTC devices 103, 104, 105, 106 may be surveillance cameras that are located in various regions across different eND service areas.
  • the MTC device 103 may send important information related to the intruder's intrusion. These important messages need to be sent in real time and require high bandwidth to capture clearly the intruder's appearance and behavior.
  • an upper limit is set for the group bandwidth
  • U-plane traffic from the MTC device 103 can reach the MTC server 102 without delay.
  • the problem of the group-based communication scenario configured by the MTC device is described. However, a person skilled in the art will be able to determine that the problem occurs in any type of group-based communication.
  • Patent Document 1 does not acquire a usable bandwidth for transmission of wide bandwidth traffic when there is no free bandwidth (Spare Bandwidth). Therefore, for example, when the AvGrBW state is set to a necessary minimum, the method of reallocating unused bandwidth is used to solve the problem related to transmission of high priority traffic described in FIG. Can not do it.
  • Patent Document 2 describes how to acquire the bandwidth for a high priority device when static priority assignment is not performed for the devices in the group. Is not presented. Therefore, the technique disclosed in Patent Document 2 cannot appropriately specify a high priority device to receive a service when priorities are not pre-assigned to the devices in the group. The problem described in FIG. 1 cannot be solved appropriately.
  • Patent Document 3 an access control mechanism when the priority of the terminal is set based on the time of traffic transmitted from the terminal is not disclosed.
  • a network entity pre-assigns a static priority to a device, the priority state is explicitly indicated by the network as in the scenario described in FIG. The problem of not being assigned to cannot be solved.
  • Patent Document 3 does not cover how high-priority traffic is accommodated in a case where the bandwidth is limited (the case illustrated in FIG. 1).
  • such a group identifier is an appropriate mechanism for realizing group optimization when communication traffic is transmitted to a plurality of devices. In order to solve the problem, it is not possible to realize a way to get high priority traffic through the network.
  • the present invention solves the above problem, when there is a group device having high priority, real time, high bandwidth user plane traffic, the available group bandwidth is not sufficient for transmission of the user plane traffic. Even if it is a case, it aims at enabling it to acquire a required bandwidth from the group bandwidth upper limit. It is another object of the present invention to allow a device to acquire a necessary bandwidth while suppressing power consumption while considering that excessive signaling from the device to the network does not occur.
  • the communication device of the present invention is a system in which a plurality of communication devices communicate with a specific communication server via a network, and is assigned to each of the plurality of communication devices.
  • the communication device in the system set so that the sum of bit rates of communication cannot exceed a predetermined upper limit value,
  • a transmission determining unit for determining whether to transmit high priority and high bit rate traffic;
  • a service request transmission unit for transmitting a service request for transmitting the high priority and high bit rate traffic to the network when it is determined to transmit the high priority and high bit rate traffic;
  • a service request response receiving unit that receives a service request response including a bearer identifier of a bearer that is a response to the service request and cannot transmit the high priority and high bit rate traffic;
  • a traffic transmission requesting unit that transmits a transmission request of the high priority and high bit rate traffic to the specific communication server via the bearer specified by the bearer identifier;
  • a traffic transmission request response receiving unit that receives a transmission request response including information indicating whether transmission of the
  • this configuration if there is a group device with high priority, real time, high bandwidth user plane traffic, even if the available group bandwidth is not sufficient for the transmission of the user plane traffic, Necessary bandwidth can be acquired from the upper bandwidth limit.
  • this configuration allows the device to acquire the necessary bandwidth while suppressing power consumption while considering that excessive signaling from the device to the network does not occur.
  • the network node of the present invention is a system in which a plurality of communication devices communicate with a specific communication server via a network, and is assigned to each of the plurality of communication devices.
  • a network node that constitutes the network in the system that is set so that a sum of bit rates of communication that cannot exceed a predetermined upper limit value
  • a service request receiving unit that receives a service request for transmitting the high priority and high bit rate traffic from the communication apparatus that has decided to transmit the high priority and high bit rate traffic;
  • a service request response transmitter that transmits a service request response including a bearer identifier of a bearer that cannot transmit the high priority and high bit rate traffic, Have.
  • this configuration if there is a group device with high priority, real time, high bandwidth user plane traffic, even if the available group bandwidth is not sufficient for the transmission of the user plane traffic, Necessary bandwidth can be acquired from the upper bandwidth limit.
  • this configuration allows the device to acquire the necessary bandwidth while suppressing power consumption while considering that excessive signaling from the device to the network does not occur.
  • the communication server of the present invention is a system in which a plurality of communication devices communicate with a specific communication server via a network, and is assigned to each of the plurality of communication devices.
  • a communication server in the system that is set so that the sum of the bit rates of the communication is not allowed to exceed a predetermined upper limit,
  • a traffic transmission request receiving unit that receives a transmission request for the high priority and high bit rate traffic from the communication device that has decided to transmit high priority and high bit rate traffic via a predetermined bearer
  • an instruction to stop the traffic is issued to a specific communication device that can stop the traffic transmission.
  • the Have With this configuration, if there is a group device with high priority, real time, high bandwidth user plane traffic, even if the available group bandwidth is not sufficient for the transmission of the user plane traffic, Necessary bandwidth can be acquired from the upper bandwidth limit. In addition, this configuration allows the device to acquire the necessary bandwidth while suppressing power consumption while considering that excessive signaling from the device to the network does not occur.
  • the present invention has the above configuration, and when there is a group device having high priority, real time, high bandwidth user plane traffic, the available group bandwidth is sufficient for transmission of the user plane traffic. Even if this is not the case, the necessary bandwidth can be acquired from the upper limit of the group bandwidth.
  • the present invention has the above-described configuration, so that the device can acquire the necessary bandwidth while suppressing power consumption while considering that excessive signaling from the device to the network does not occur. Has the effect of
  • Diagram showing a group-based communication model in the prior art The figure which shows an example of a structure of the group-based communication model in embodiment of this invention
  • movement in embodiment of this invention The sequence chart which shows the 2nd example of operation
  • movement in embodiment of this invention The sequence chart which shows the 4th example of operation in an embodiment of the invention
  • movement in embodiment of this invention The figure which shows an example of a structure of the MTC device in embodiment of this invention
  • the flowchart which shows an example of the process of the MTC device in embodiment of this invention
  • Sequence chart showing a sixth example of the operation in the embodiment of the present invention The sequence chart which shows the 7th example of operation in an embodiment of the invention
  • a group of mobile devices for example, a group of MTC devices
  • a device having such a high-priority U-plane traffic uses a signaling process to the network to notify its traffic state, and there is no available group bandwidth in the network. There is a minimum bandwidth bearer acquisition.
  • the device After obtaining such a minimal bandwidth bearer, the device informs the server that it is in a critical state (ie, cannot send high priority U-plane traffic), so that the server Stops transmission of other devices in the group that are not sending significant U-plane traffic to obtain the available group bandwidth for devices with high priority U-plane traffic.
  • a critical state ie, cannot send high priority U-plane traffic
  • a group of devices determines their priority state associated with application layer traffic and notifies the transmission of high priority U-plane traffic to the network. Furthermore, the minimum bandwidth bearer given from the network (3GPP network) is used to notify the server of the U plane traffic state and the state where there is no group bandwidth available. In order to suspend transmission of devices having low priority U-plane traffic and reserve bandwidth for devices having high priority U-plane traffic and requesting bandwidth, the server Is used to identify the U-plane traffic status of other devices in the group and release the bandwidth used for low-priority U-plane traffic. Finally, in order to be able to forward high priority U-plane traffic without significant delay, the fact that the group bandwidth required for high priority U-plane traffic is available will The device that has it is notified.
  • FIG. 2A ⁇ Operation scenario of the present invention>
  • devices can communicate with a server through broadband access media or other types of access media or network architecture.
  • the present invention is also applicable when one of the devices in the group functions as a server in a group-based communication model.
  • the scenario shown in FIG. 2A relates to an MTC device communicating with an MTC server, but there is no restriction on the type of device to which the present invention is applied.
  • the device receives a service.
  • a normal mobile terminal having a function of connecting to a network.
  • the MTC devices 200a, 201a, 202a, and 203a use group-based communication with a server such as the MTC server 214a. Furthermore, it is assumed that the MTC devices 200a, 201a, 202a, and 203a use the 3GPP core network 212a to transmit user plane and control plane traffic to related endpoints.
  • the user plane traffic of the MTC devices 200a, 201a, 202a, and 203a shown in FIG. 2A includes a tunneling mechanism from the eNB to the serving gateway (S-GW), and another from the S-GW to the P-GW. It is assumed that the MTC server 214a is reached by the independent tunneling mechanism.
  • the 3GPP core network 212a illustrated in FIG. 2A may be a 3GPP extended packet core (evolved packet packet (EPC)) described in Non-Patent Document 2. Further, the core network 212a may be a general packet radio service (GPRS) core network or a universal mobile telecommunication system (UMTS) core network, and the present invention is also applicable thereto.
  • FIG. 2A shows a configuration when LTE is used as the access system. However, when UMTS is used, eNB is replaced with RNC / BSC, MME is replaced with SGSN, and PGW is replaced with GGSN.
  • the MTC devices 200a, 201a, 202a, 203a shown in FIG. 2A are deployed by a single subscriber and are independent areas that do not overlap each other (or only partially overlapping areas). Is located). Arranging an MTC device in an independent area indicates that the MTC device is arranged in an independent eNB service area or cell. Such an arrangement is the most realistic arrangement. This is because not all MTC devices are located in the same area, but in most cases, MTC devices are used to transmit information from different areas. However, in the rare case where there are a large number of machine type data to be detected in the area, a plurality of MTC devices may be arranged at predetermined positions for the purpose of load balancing among the MTC devices. Is possible. In general, considering that MTC devices do not have much data to send, it is very common for MTC devices to be placed in independent, non-overlapping areas for data collection, processing, and transmission to MTC servers. It is a realistic arrangement.
  • the MTC devices 200a, 201a, 202a, and 203a are connected to the eNBs 204a, 205a, 206a, and 207a, respectively, as shown in FIG. 2A, based on an arrangement model in which the MTC devices do not overlap.
  • the MTC devices 200a and 201a attempt to send a NAS message (tracking area update, service request) to the MME 208a
  • the eNB 204a and the eNB 205a may communicate with the MME 208a for each of the MTC device 200a and the MTC device 201a.
  • Set up the S1 control plane connection S1-MME, S1-AP (Application-Protocol)).
  • a GTP bearer or PMIP tunnel from the S-GW 209a to the P-GW 213a is set up for the MTC devices 200a and 201a, and similarly, a GTP from the S-GW 210a to the P-GW 213a for the MTC devices 202a and 203a.
  • a bearer or PMIP tunnel is set up.
  • a group of MTC devices may be connected and managed by different eNBs, MMEs, and S-GWs.
  • the same P-GW 213a can be assigned by the static configuration stored in the HSS.
  • the P-GW 213a is assumed to be an entity that confirms the communication status with respect to the G-AMBR upper limit (G-AMBR implementation point), a point that calculates AvGrBW, an entity that notifies AvGrBW information, or an entity that distributes it.
  • the operation scenario illustrated in FIG. 2A is a case where all MTC devices in the group are connected to different eNBs, and as a result may be connected and managed to different MMEs and S-GWs.
  • the present invention is also applicable to a scenario where all MTC devices of a group-based communication model communicating with an MTC server can be connected to the same eNB, the same MME, or the same S-GW.
  • the G-AMBR implementation point may be the S-GW instead of the P-GW.
  • the S-GW holds the G-AMBR, a new process for triggering a bearer modification process that allows the AvTC to notify the MTC device of AvGrBW has been introduced to the S-GW. Need to be done.
  • the present invention is applicable to practical real-world scenarios where devices with such group-based bandwidth limitations need to transmit high priority, high bandwidth, real-time U-plane traffic to the server. It is.
  • the present invention has high priority U-plane traffic to be sent to the server while devices belonging to a group have limited group bandwidth, while some of the other devices in the group This is applicable when high priority U-plane traffic is not sent to the server.
  • this embodiment of the present invention relates to an M2M group-based communication scenario, the present invention can be applied to many other non-M2M scenarios without departing from the scope of the present invention. Is possible.
  • an MTC subscriber may use a plurality of MTC devices for acquiring images of theft or vandalism in a home or office using a surveillance camera.
  • An example of deployment is given.
  • the surveillance camera updates the monitored event with respect to the common MTC server for theft prevention and theft detection.
  • Surveillance cameras with an MTC function have limited power and may be battery powered. Also, it is assumed that not all monitoring cameras in the group are simultaneously transmitting the same type of U-plane traffic to the MTC server.
  • a surveillance camera when a surveillance camera detects an intruder, it attempts to send high priority U-plane traffic that captures the intruder's face, behavior and actions at high resolution to the server, so a wide bandwidth is required. While a given surveillance camera is trying to send high priority U-plane traffic to the MTC server, another surveillance camera in the group sends normal traffic that captures the normal activities of the home or office to the MTC server. May have. Thus, the present invention is applicable to obtain a minimum bandwidth bearer for surveillance cameras that are trying to send high priority U-plane traffic but do not currently have sufficient bandwidth. . When the surveillance camera obtains the minimum bandwidth bearer to notify the MTC server that the available group bandwidth is insufficient, it transmits a warning message via the minimum bandwidth bearer.
  • the MTC server To notify the MTC server of this state.
  • the MTC server receives the information indicating that the bandwidth is insufficient from the monitoring camera, the MTC server cancels the session of the other low-priority camera, and further allocates the bandwidth to the high-priority monitoring camera. Notify you to start the service.
  • M2M group-based communication to which the present invention is applicable is, for example, an example in which an MTC device having a camera function is arranged to capture a real-time event and report it to an MTC server as entertainment.
  • these MTC devices operate without human intervention to capture events in real time and send events to MTC servers located at television broadcast stations using multimedia traffic.
  • another communication scenario based on the M2M group to which the present invention can be applied is, for example, a case where an MTC device of a certain group updates traffic related to human health to the MTC server.
  • the stream of traffic from the MTC device may include, for example, human heartbeat, body temperature, blood glucose level.
  • the MTC device for health monitoring is utilized using the main method of the present invention. It is desirable to grant access permission for high priority U-plane traffic from.
  • it is intended to be able to transmit high priority U-plane traffic from a health monitoring device without significant delay.
  • this MTC device is notified when the available group bandwidth (ie, uplink AvGrBW) is 0 May not be able to transmit U-plane uplink traffic. Since the default bearer is a non-GBR bearer, it is assumed that this MTC device can transmit U-plane uplink traffic if the reported available group bandwidth is greater than zero. Further, it is assumed that whenever the value of AvGrBW is changed, the state of the available group bandwidth is notified to this MTC device by using a bearer change process that does not perform bearer QoS update.
  • the available group bandwidth ie, uplink AvGrBW
  • AvGrBW is notified using a single bearer change process instead of bearer QoS update signaling. This is because AvGrBW is not a parameter associated with a given default bearer but a parameter associated with an MTC device.
  • this MTC device is defined as a predetermined bearer or bearer ID.
  • AvGrBW notifications may be received. That is, AvGrBW is notified using a single bearer change process that does not perform bearer QoS update.
  • a single bearer change signaling is used to provide the value of AvGrBW to the MTC device even if there are multiple non-GBR bearers. This is because all bearers are non-GBR bearers and there is no bandwidth associated with them, so the network will only advertise AvGrBW not associated with a bearer identifier.
  • the MTC device transmits uplink U plane traffic when AvGrBW is greater than 0, and does not transmit uplink U plane traffic when AvGrBW is 0.
  • MTC devices in the group can perform U-plane traffic transmission using either a non-GBR dedicated bearer or a default bearer when AvGrBW is notified that it is higher than 0.
  • the AvGrBW notification indicates that the P-GW performs bearer change signaling for each dedicated (GBR) bearer. Transmit independently and notify the changed bandwidth for each GBR bearer. This is because the bandwidth is related to the GBR bearer, so the network divides the AvGrBW among the GBR bearers and consequently transmits bearer change signaling for each bearer. For example, if AvGrBW is x, the P-GW performs multiple bearer modification processes for each of the GBR bearers in order to allocate most of the available bandwidth to the GBR bearers in a symmetrical or asymmetrical manner.
  • the MTC device can determine whether this GBR value is sufficient for transmission of traffic and select an associated GBR bearer or default bearer.
  • the P-GW allocates most of the available group bandwidth, that is, AvGrBW to the GBR bearer. And allocate the minimum bandwidth of AvGrBW to the default bearer and the non-GBR bearer.
  • the P-GW performs a plurality of bearer QoS changing processes for the GBR bearer, and notifies the bandwidth allocated to each GBR bearer.
  • the P-GW performs a single bearer change process that does not perform bearer QoS update, and collectively notifies the available bandwidth for the default bearers and non-GBR bearers.
  • the MTC device can then transmit traffic via one or more non-GBR bearers using the available bandwidth value transmitted in the bearer change process without performing bearer QoS update. Similarly, the MTC device uses bearer QoS updates for individual received GBR bearers in selecting the relevant GBR bearer for uplink traffic transmission.
  • the bandwidth of the GBR bearer that is not used for U-plane traffic is the bandwidth in the AvGrBW calculation process.
  • the first step is to identify the total bandwidth being used in a group of MTC devices. This bandwidth is the bandwidth related to the U-plane traffic of the MTC device. After specifying the bandwidth used in the group, the available group bandwidth can be specified.
  • the used bandwidth only the bandwidth related to the actual U-plane traffic is considered as the used bandwidth, and the bandwidth related to the unused GBR bearer is not considered.
  • An unused GBR bearer is a GBR bearer that is not currently transmitting U-plane traffic.
  • GBR bearers are considered high priority bearers, and these bearers are used in the group even if U-plane traffic is not currently being transmitted via the GBR bearer. It can be used to calculate bandwidth.
  • the bandwidth associated with the GBR bearer is always available for MTC devices that are allowed GBR bearers, regardless of whether or not U-plane traffic is transmitted via the GBR bearers. It becomes possible.
  • always reserving a fixed bandwidth for a GBR bearer is not an efficient resource management model.
  • the MTC device enters the network to establish a special dedicated GBR bearer with a bandwidth that has always been shown to be available in the computation of available group bandwidth. It is possible to request. By having such a bearer, the MTC device can immediately use this special dedicated GBR bearer for transmission of high priority traffic, and there is no need to consider AvGrBW.
  • QoS bearer management processing particularly describes bearer management processing in 3GPP EPS.
  • bearer management processing described when executing G-AMBR is the UTC of the MTC device. It will be appreciated that the present invention is also applicable when plain traffic is transmitted through GPRS cores or UMTS cores or other systems utilizing bearer management.
  • Sending bearer change signaling to inform all MTC devices in the group that are not currently scheduled to send U-plane traffic is an unnecessary signaling as described above to inform AvGrBW allocation between bearers. Is a waste of network resources. Further, if the MTC device does not plan to transmit uplink U-plane traffic, bringing up the MTC device from idle mode and notifying the entire bearer AvGrBW distribution is a waste of power of the MTC device.
  • MTC devices 200b and 201b are MTC devices that belong to a group of MTC devices that perform group-based communication with the MTC server 204b. Furthermore, it is assumed that the MME selected by each eNB for the MTC devices 200b and 201b is the MME 202b. Furthermore, it is assumed that the G-AMBR execution point and the AvGrBW calculation point are P-GW 203b. Furthermore, it is assumed that the MTC device 200b is in the idle mode, while the MTC device 201b is in the connection mode, and is transmitting U-plane traffic to the MTC server 204b.
  • the distribution of AvGrBW between the bearers of AvGrBW and MTC device 200b is notified to MME 202b using the associated bearer change process.
  • the MME 202b knows that the MTC device 200b is in the idle mode, it does not transmit these bearer contexts to the MTC device 200b, but instead stores them in the storage means of the MME 202b.
  • the P-GW 203b transmits a bearer change message of a bearer related to the AvGrBW and related to the MTC device 200b using the signaling message 205b.
  • the content of the message 205b is stored in the MME 202b and is not transferred to the MTC device 200b.
  • the MTC device 200b transitions from the idle mode to the connected mode, and transmits the service request message 206b to the MME 202b.
  • the MME 202b can check the AvGrBW stored for the MTC device 200b to confirm whether the AvGrBW is sufficient for the MTC device 200b.
  • the AvGrBW of the MTC device 200b is notified to the MME 202b by the bandwidth information embedded in the bearer change message 205b. If AvGrBW is 0 as shown in state 207b, MME 202b can send service request response message 208b and reject the service request with the appropriate item value (clause). Note that the item value can be, for example, rejection due to lack of AvGrBW.
  • the MME 202b simply notifies the bandwidth related to the default bearer or the dedicated GBR bearer in the service response processing 208b, and informs the MTC device 200b whether the bandwidth is sufficient for U-plane traffic transmission. You just have to decide. In such a case, the MME 202b notifies the bandwidth value related to the bearer by the new information element of the service response NAS message 208b, and does not reject the service request by the item value of rejection.
  • the MME 202b determines whether the service acceptance message or the AvGrBW distribution in the bearer of the MTC device 200b or the AvGrBW Send a denial of service message. If there is a single GBR bearer that supports the requested bit rate, the GBR bearer is granted and the bearer identifier is notified by the service request response message 208b. If AvGrBW is greater than 0 but not sufficient to support the requested bit rate, a denial of service is sent in message 208b.
  • the MME 202b rejects the service request 206b and further sets a new bearer value. Notification, waiting for bearer information, and not retrying the service request until paging is received. Such waiting for paging information can be sent by message 208b.
  • the MME 202b may request the P-GW 203b to establish a bearer for the MTC device 200b. In order to realize this new bearer, the existing GBR bearer needs to be discarded and a new GBR created.
  • the MME 202b can send paging to the MTC device 200b.
  • the MTC device 200b receives the paging and executes a service request to the MME 202b.
  • the attributes of the new GBR bearer that enables uplink U-plane traffic transmission are sent to the MTC device 200b.
  • the MTC device 200b waits for a random time and then retries the service request to enter the connection mode.
  • a retry service request is illustrated as signaling message 209b in FIG. 2B. Again, it is assumed that no device in the group stops transmitting uplink U-plane traffic, and there is no change in the state of AvGrBW in MME 202b. The absence of a state change during this retry service request is shown as state 210b. In this case, the MME 202b transmits another service request rejection message 211b to the MTC device 200b.
  • the MTC device 201b stops U-plane traffic transmission and, as a result, transmits a transmission stop message 212b to the MME 202b.
  • the message 212b is an optional message and does not necessarily have to be transmitted.
  • the MTC device 201b can transmit a detach NAS message 212b to the MME 202b when performing detachment from the network.
  • the detach message 212b is further transmitted to the P-GW 203b for detach notification.
  • the P-GW 203b recalculates AvGrBW.
  • the new AvGrBW is notified to the MME 202b using the signaling message 214b. Note that the AvGrBW notified by the signaling message 214b is sufficient to transmit the uplink U-plane traffic of the MTC device 200b.
  • the MME 202b that has received the message 215b for retrying the service request again transmits the service request acceptance message 217b to the MTC device 200b because the available group bandwidth is available (state 216b).
  • the MTC device 200b successfully transmits U-plane traffic to the MTC server 204.
  • This U-plane traffic is indicated by message 218b.
  • the advantage of this method is that it is not always necessary to transmit bearer information, and that notification is performed only when the MTC device is trying to transmit data and transmits a service request. This solves the problem that unnecessary signaling and paging signaling of the core network are transmitted, and also saves the power of the MTC device.
  • the method illustrated in FIG. 2B requires that the MTC device 200b with high priority traffic to transmit still wait for some amount of time to obtain the required bandwidth, There is also a problem that the MTC device 200b has to execute service request signaling a plurality of times and shift to the connection mode.
  • the MTC device 200b When the MTC device 200b changes from the detach mode to the attach mode, the MTC device 200b receives bearer related information using a normal bearer creation process. In attach mode, the MTC device 200b can query the MME 202b to obtain relevant bearer parameters, or the MME 202b can pass without storing bearer information.
  • attach mode the MTC device 200b can query the MME 202b to obtain relevant bearer parameters, or the MME 202b can pass without storing bearer information.
  • This arbitrary network architecture is a general architecture mainly composed of three components (for example, an MTC device, an MTC server, and a network component for the MTC device to reach the MTC server).
  • This network component can be thought of as constituted by routers and gateways that allow transmission of user plane traffic and control plane traffic from the MTC device.
  • This network component can also be considered to constitute an access network, a transmission network, and even the general Internet.
  • the network component can create and maintain single or multiple bearers for each connected MTC device.
  • the bearer has the feature of the level of QoS support provided for U-plane traffic.
  • the MTC device is an arbitrary mobile device.
  • the present invention is applicable to a general setting in which this MTC server is an arbitrary type of server.
  • FIG. 3A Before describing the details of such signaling exchange, first, the high-order operation of the present invention will be described with reference to FIG. 3A.
  • the network 301a is an arbitrary network entity in the path between the MTC device 300a and the MTC server 302a.
  • the operation according to the invention illustrated in FIG. 3A indicates that the MTC device 300a needs to transmit high priority, high bandwidth, real-time U-plane traffic to the network 301a (which means a network entity).
  • a minimal bandwidth bearer means that the bearer is associated with a minimal bandwidth and a low QoS.
  • the network 301a gives the minimum bandwidth bearer low QoS does not require the network 301a to preferentially handle U-plane traffic when it is transmitted through this bearer, and as a result, via the minimum bandwidth bearer This means that the U-plane traffic transmitted in this manner does not affect the U-plane traffic flow of other devices.
  • the other device may not be a device of the group.
  • the network 301a allows the U.S. critical resources from other devices not belonging to the group to be transmitted via the minimum bandwidth bearer. This means that it does not need to be used for plain traffic.
  • the network 301a determines the bearer having the minimum bandwidth
  • the network 301a notifies the MTC device 300a of the bearer identifier of the bearer having the minimum bandwidth. If the MTC device 300a determines that the bearer returned by the network 301a is the bearer of the minimum bandwidth, the MTC device 300a knows the QCI associated with it based on the static configuration, and bearers related to U-plane traffic transmission.
  • QoS QoS parameters (that is, bandwidth and link buffer characteristics) are adjusted internally. Each QCI scalar is considered to be mapped to an arbitrary QoS parameter.
  • the network 301a may be the bearer of the minimum bandwidth bearer.
  • a QCI scalar value for a bearer with a minimum bandwidth and a QoS parameter corresponding to the QCI scalar may be explicitly given to the MTC device 300a.
  • the MTC device 300a When the MTC device 300a is informed about this minimum bandwidth bearer, it sends a warning message to the bearer to obtain some bandwidth capable of forwarding high priority, broadband, real-time U-plane traffic. It is correctly determined as a bearer that can be used for transmission to the MTC server 302a. After determining the characteristics of the minimum bandwidth bearer, the MTC device 300a internally adjusts the QoS parameters to use this minimum bandwidth bearer. The MTC device 300a adjusts the U-plane traffic transmission rate to the minimum value associated with the QCI of the minimum bandwidth bearer and sends the QCI corresponding to the minimum bandwidth bearer to the internal uplink buffer. input.
  • the MTC device 300a uses this minimum bandwidth bearer to notify the MTC server 302a that the network 301a is in a state of insufficient bandwidth.
  • AvGrBW is 0 or more, but even when the U-plane traffic rate required for the MTC device 300a is larger than AvGrBW, the network 301a may allocate a bearer with the minimum bandwidth to the MTC device 300a. is important.
  • the MTC server 302a When a bandwidth that has been used after the warning is transmitted to the MTC server 302a is released and a bandwidth that exceeds AvGrBW exists, the MTC server 302a notifies the MTC device 300a that the bandwidth has been released. When the bandwidth availability state is recognized by the MTC device 300a, the MTC device 300a requests the network 301a to restore the QCI for the bearer with the minimum bandwidth and uses it to take high priority. , Wide bandwidth, real-time U-plane traffic is sent to the MTC server 302a.
  • the MTC device 300a sends a service request signaling 303a to inform it that it is scheduled to send high priority, wide bandwidth, real time traffic.
  • the trigger that indicates that the MTC device 300a is trying to send high priority, high bandwidth, real time traffic can be in any form, for example, bit rate, bandwidth, U-plane traffic characterizing such a need, Or some identifier may be sufficient.
  • Network entity 301a checks the AvGrBW for that group. If the AvGrBW for that group is 0, the network entity 301a notifies the MTC device 300a that only bearers with the minimum bandwidth are available. Information about such a minimum bandwidth bearer is provided in response message 304a.
  • the MTC device 300a Upon receipt of the response message 304a, the MTC device 300a performs the operations necessary to set up a minimum bandwidth bearer. It should be noted that bearer setup with minimal bandwidth can be performed with or without explicit signaling.
  • the response message 304a may be a service request response message (Service (Accept) including a value indicating a time interval (back-off timer) in which only a minimum amount of data can be sent.
  • Service Accept
  • back-off timer a time interval
  • the MTC device 300a determines that high priority or broadband traffic cannot be transmitted until the received timer elapses.
  • the back-off timer indicates that the bearer corresponding to the service request transmitted by the MTC device 300a is established after a certain time (the back-off timer has elapsed).
  • the entity in the network 301a that notifies the back-off timer is the MME.
  • MTC device 300a After MTC device 300a knows the presence and configuration of such a minimum bandwidth bearer, it uses the minimum bandwidth bearer to alert MTC server 302a as indicated in message 305a. Send a message. Further, as described above, when the back-off timer is included in the response message 304a received from the network 301a, the minimum bandwidth is maintained while the back-off timer received from the network 301a is valid. Is used to send a warning message to the MTC server 202a as shown in message 305a. This warning message 305a is considered to be a user plane message, and is specifically transmitted to request some bandwidth. The MTC server 302a communicates with the network 301a to acquire the bandwidth for the group or use some means to release the bandwidth for the MTC device 300a.
  • the above-mentioned means may be to notify the MTC server 302a of stopping transmission when other MTC devices are not transmitting very important U-plane traffic to the MTC server 302a.
  • the exchange between the MTC server 302a and the network 301a is not explicitly shown in FIG. 3A.
  • the MTC server 302a After confirming that the necessary bandwidth is available for the MTC device 300a, the MTC server 302a transmits a clear-to-send (CTS) application layer message 306a to the MTC device 300a.
  • CTS clear-to-send
  • the purpose of the message 307a is to request a bearer with minimal bandwidth to restore higher QoS characteristics, so that the MTC device 300a can receive high priority, high bandwidth, real-time U-plane traffic. It becomes possible to transmit to the MTC server 302a. Also, the MTC device 300a knows that another predetermined bearer other than this minimum bandwidth bearer allocated to the MTC device 300a is sufficient to transmit U-plane traffic to the MTC server 302a. If so, the MTC device 300a may perform bearer changes for such bearers that are not minimal bandwidth bearers.
  • the network entity 301a checks whether the current AvGrBW is sufficient before accepting the bearer change request by the message 307a. If the network entity 301a knows that there is sufficient bandwidth to meet the requirements embedded in the message 307a, it sends an acknowledgment as shown in the message 308a. In the acknowledgment message 308a, the network entity 301a assigns a minimum bandwidth bearer identifier or another existing one that can carry the high priority, wideband, real-time U-plane traffic of the MTC device 300a. Assign bearer identifiers. When the message 308a is received, the MTC device 300a transmits a U-plane message in which the bearer ID is added to the message 308a to the MTC server 302a. The U plane data message to the MTC server 302a is illustrated by message 309a.
  • the method of the present invention is applied.
  • a minimum bandwidth bearer with reduced QoS is set up to communicate with the MTC server 302a using the method of the present invention so that the MTC server 302a transmits low priority traffic. It is possible to remove other MTC devices that perform and return the AvGrBW state to a higher value.
  • this minimum bandwidth bearer notifies the MTC device 300a or router of the modified QoS if the QoS of the existing bearer is modified. Therefore, a bearer with a minimum bandwidth is allocated to the MTC device 300a without adding explicit bearer change signaling in the network.
  • the minimum bandwidth bearer ID is added and the router on the path has this ID minimum. It knows that it is related to the bearer of the bandwidth, and performs the minimum QoS processing necessary for U-plane traffic. Note that the ID of the bearer with the minimum bandwidth is unique and is related only to the minimum bandwidth bearer.
  • a router on the U-plane traffic path does not receive explicit bearer change signaling from the network, it does the QoS processing to be performed when it confirms the bearer ID of the minimum bandwidth.
  • the bearer ID is changed to the ID of the bearer with the minimum bandwidth.
  • the ID of the minimum bandwidth bearer is mapped to a specific QoS, and such mapping is also stored in advance in the router and the MTC device 300a. It is thought that there is.
  • the first case is when the MTC device has only a default bearer, and the default bearer with reduced QoS is considered as the bearer with the minimum bandwidth.
  • the second case is a case where the MTC device has a default bearer and a dedicated bearer, and only the default bearer is assigned as the bearer with the minimum bandwidth without reducing the QoS of the default bearer.
  • the default bearer is used as a minimum bandwidth bearer, the QoS associated with the default bearer is low and the QoS parameters for the default bearer need not be reduced. Therefore, in the second case, it is not necessary to change the QCI value as in the first case.
  • the MTC devices 300b and 301b normally communicate with the MTC server 304b and are charged with G-AMBR. Further, it is assumed that the MTC devices 300b and 301b are assigned IP addresses from a network entity 303b such as a P-GW, for example. Hereinafter, it is assumed that the network entity 303b is a P-GW. Further, it is assumed that the MTC devices 300b and 301b are connected to the MME 302b. In such 3GPP-oriented setting, it is assumed that the MTC device 301b has a U-plane communication session with the MTC server 304b. Furthermore, it is assumed that the MTC device 300b has high priority, wide bandwidth, and real-time U-plane traffic to be transmitted to the MTC server 304b, and the MTC device 300b is currently in the idle mode.
  • a network entity 303b such as a P-GW
  • the MTC device 300b has only the default bearer.
  • the scenario is fully conceivable.
  • the MTC device 300b sends a service request message as shown in the message 305b.
  • the MTC device 300b can embed a flag in this service request message 305b to indicate that it needs to transmit high priority, wide bandwidth, real time U-plane traffic. This flag may be a new information element added to the service request message 305b.
  • the MTC device 300b can also embed an explicit bit rate and bandwidth profile in the message 305b.
  • the MTC device 300b transmits a flag of the message 305b, and the MME 302b that confirms the flag can acquire the traffic profile related to the MTC device 300b from the stored cache or database. It is.
  • the traffic profile of the MTC device 300b is statically configured in the MME 302b.
  • the MME 302b can transmit a service request response message to the MTC device 300b as shown in the message 307b.
  • This response message 307b desirably notifies the bearer ID of the bearer with the minimum bandwidth to the MTC device 300b.
  • the bearer change message is not transmitted to the MTC device, and it is possible to maintain bearer information in the MME 302b.
  • the MME 302b has all the information about the bearer of the MTC device 300b and can immediately respond with an appropriate message 307b.
  • This bearer information may include AvGrBW information.
  • the MTC device 300b receives the message 307b and confirms the bearer ID of the bearer with the minimum bandwidth, the MTC device 300b knows that this bearer ID is temporarily assigned to the default bearer, and the network further recognizes the MTC device 300b. Understand that we intend to allocate a minimum bandwidth bearer to In another embodiment, a new information element (Cause Value) can be assigned to the response message 307b, and the MTC device 300b can interpret it as permission of a bearer with a minimum bandwidth. It is.
  • the MTC device 300b can specify the ID of the bearer with the minimum bandwidth configured in advance stored in the MTC device 300b. . It is considered that the MTC device 300b already knows the bearer ID related to the minimum bandwidth bearer by the pre-configuration, and can immediately specify the information in the response message 307b. Even if there is no prior configuration, the MTC device 300b may determine that the new bearer ID is present in the response message 307b as the bearer ID of the bearer with the minimum bandwidth.
  • the response message 307b includes a back-off timer, it is interpreted that only a bearer with a minimum bandwidth is permitted while the timer is valid. That is, when the expiration date of the timer expires, it is determined that a normal bearer can be generated, and a service request for high priority / broadband is transmitted.
  • the MTC device 300b When sending U-plane traffic using a minimum bandwidth bearer, the MTC device 300b knows that a minimum bandwidth bearer is allocated, as described above, and then internally Change the QoS.
  • the minimum bandwidth bearer is the default bearer, and the MTC device 300b associates the new QCI with the default bearer. Such internal association is indicated by operation 308b.
  • the MTC device 300b associates the minimum bandwidth bearer ID with the user plane packet to send a U-plane warning message 309b to the MTC server 304b. Send. Note that those skilled in the art will change the default bearer ID to the static minimum bandwidth bearer ID, so that all routers perform the minimum QoS processing on the message 309b. You will understand.
  • the MTC device 300b transmits very low bandwidth U-plane traffic to the MTC server 304b in order to notify the state to the MTC server 304b.
  • the MTC server 304b determines a method for acquiring a bandwidth necessary for the MTC device 300b.
  • the message 309b may include bit rate information for high priority U-plane traffic that the MTC device 300b is attempting to transmit. By grasping such bit rate information, the MTC server 304b can easily grasp the amount of bandwidth to be released to accommodate the MTC device 300b. If the MTC server 304b has bit rate monitoring characteristics, the MTC server 304b identifies all other devices in the group that need to stop transmitting to obtain bandwidth for the MTC device 300b. It is possible.
  • the MTC server 304b can predict that the flow of the other MTC device is not so important, it is considered that it is only necessary to stop the transmission of the other MTC device. If the MTC server 304b does not have such a bit rate monitoring characteristic, it is possible to communicate with the P-GW 303b so as to obtain assistance in identifying an MTC device that needs to be shut down. However, since the MTC server 304b has an application layer and has a function of identifying an MTC device in a group that is not transmitting high priority traffic, an MTC device that can stop transmission is It is specified only by the MTC server 304b.
  • the MTC server 304b When the MTC server 304b specifies that the U-plane traffic of the MTC device 301b can be stopped, the MTC server 304b transmits a transmission stop message to the MTC device 301b using the message 310b.
  • the MTC server 304b In order to ensure that the bandwidth is provided to the MTC device 300b and not to be used by another MTC device, the MTC server 304b explicitly indicates the bandwidth required in the MTC device 300b to the P-GW 303b. You may request to make a reservation. According to this operation, the AvGrBW value related to the MTC device 300b increases and the AvGrBW value related to other devices decreases due to the reservation.
  • the MTC server 304b When the MTC server 304b recognizes that sufficient bandwidth is available for the MTC device 300b, it transmits a CTS message to the MTC device 300b. This CTS message is indicated by message 311b.
  • the MTC device 300b decides to perform a bearer change for the default bearer. The bearer change is made to restore the QoS characteristics of the default bearer to a higher value. As a result, the MTC device 300b can transmit high priority, wide bandwidth, real-time U-plane traffic.
  • the MME 302b If the MME 302b receives the default bearer change request message 312b and has information that it is an AvGrBW larger than the associated bandwidth (state 313b), the MME 302b performs a bearer change process for the default bearer. Restore the QCI.
  • the default bearer ID (different from the ID of the bearer with the minimum bandwidth) is returned to the MTC device 300b by the bearer change request response message 314b.
  • the MTC device 300b When receiving the default bearer ID by the message 314b, the MTC device 300b starts transmission of the uplink traffic 315b to the MTC server 304b.
  • the MTC device 300b in the bearer change request message 312b, can request a new dedicated bearer and transmit high priority traffic.
  • the network can create a dedicated bearer instead of changing the default bearer. The ID of the newly created dedicated bearer can be notified by the message 314b.
  • the existing default bearer is simply notified to the MTC device 300b by the response message 307b as a bearer with the minimum bandwidth.
  • the MTC device 300b may associate multiple bearers with it.
  • the response message 307b simply carries the default bearer ID.
  • the MTC device 300b can use only the default bearer to send the warning message 309b to the MTC server 304b, and the default bearer with no change is minimal. It can be determined that it is a bandwidth bearer.
  • the MTC device 300b When the MTC device 300b confirms the response message 307b, the MTC device 300b also determines that the warning message 309b needs to be transmitted with a minimum bandwidth.
  • the QoS of the default bearer is very low, and it is considered that no further internal modification of the QoS by the MTC device 300b is necessary. Therefore, step 308b need not be performed.
  • the response message 307b includes a back-off timer, it is determined that the default bearer is the bearer with the minimum bandwidth while the timer is valid. Also good. While this back-off timer is valid, it is also determined that the warning message 309b needs to be transmitted on the default bearer.
  • the MTC device 300b may have a higher QoS than the QoS associated with the default bearer in the bearer change request 312b. It is possible to make a request to change the default bearer to have or to request a bearer change to an existing dedicated bearer. Note that the MTC device 300b can simply request a new dedicated bearer instead of the message 312b.
  • the MME 302b determines how to process the request 312b. There are a number of ways in which the MME 302b can process the request 312b, and no matter which method is used, it does not affect the main points of the present invention.
  • a dedicated bearer with a minimum bandwidth is generated as shown in FIG. It is appropriate to improve the QoS characteristics of the width dedicated bearer. Thus, it may be useful to generate a dedicated bearer with a minimum bandwidth.
  • a dedicated bearer with a minimum bandwidth may be used together with a default bearer. In this case, a dedicated bearer with minimal bandwidth may be used for traffic that requires minimal QoS.
  • the MME maintains a bearer context associated with AvGrBW related to one or more bearers of the MTC device, and the bearer context is transferred to the MTC device until the MTC device performs service request processing. It is possible not to provide to.
  • This bearer context is considered to be provided from the P-GW using a bearer change process initiated by the P-GW. Hereinafter, such operation will be described in detail.
  • the MTC devices 300c and 301c communicate with a normal MTC server and are a group-based communication scenario. Further, it is assumed that the G-AMBR is imposed on the MTC device communicating with the MTC server 304c. Further, it is assumed that the MTC device 301c is currently transmitting uplink traffic to the MTC server 304c, while the MTC device 300c is in the idle mode. Note that the MTC device 300c may have a plurality of related bearers. Furthermore, it is assumed that the MTC device 300c has U-plane traffic to be transmitted to the MTC server 304c after a certain elapsed time.
  • the U-plane traffic that the MTC device 300c intends to transmit is a high-priority, broadband, and real-time type traffic.
  • the MTC device 300c has appropriate application layer intelligence capable of classifying U-plane traffic such as high priority and broadband traffic.
  • the application layer of the MTC device 300c further passes such traffic classification (ie, high priority and broadband) to the NAS layer so that service requests initiated at the NAS layer are in the high priority in the service request message.
  • traffic classification ie, high priority and broadband
  • the MTC device 300c transmits a service request message 305c to the MME 302c.
  • the service request message 305c includes an information element indicating that the MTC device 300c is executing a service request regarding high priority and broadband traffic transmission.
  • the MME 302c Upon receiving the service request signaling message 305c, the MME 302c first checks whether the AVGrBW is sufficient to transmit the traffic profile of the MTC device 300c. Such traffic profile or traffic characteristics may be embedded in the service request message 305c, and the parameter of such traffic profile may be a bit rate. As indicated by state 306c, if the AvGrBW is not sufficient so that it cannot support the request for signaling message 305c, MME 302c initiates a dedicated bearer generation process with minimal bandwidth. Such minimal bandwidth bearer creation signaling process is illustrated by message 307c. A dedicated bearer with minimal bandwidth has a lower QCI (QoS) than the one with which the default bearer is normally associated.
  • QoS QCI
  • the default bearer is used for U-plane traffic and is considered to have a relatively high QoS handling.
  • the dedicated bearer with the minimum bandwidth is mainly used to send a warning or help trigger to the MTC server 304c, the dedicated bearer with the minimum bandwidth needs to be processed with high QoS. Absent.
  • a dedicated bearer with minimal bandwidth is associated with a very small bandwidth.
  • MME 302c may determine which bearer for traffic associated with MTC device 300c. Is checked (ie bearer identifier). If the service request 305c desires a GBR bearer and the bandwidth for the GBR bearer of the MTC device 300c is sufficient for the transmission of traffic, the GBR bearer is provided. In addition, if such a GBR bearer request is not provided by the message 305c and the bandwidth available for the non-GBR bearer pool is sufficient for traffic transmission, the non-GBR bearer is provided.
  • the required bearer is a GBR bearer with an arbitrary amount of bandwidth, but there is no GBR bearer with the required bandwidth value for the MTC device 300c, the MME 302c And one broadband GBR bearer for the MTC device 300c is generated.
  • the request may be any bearer, and if the bandwidth associated with the non-GBR pool is not sufficient, the GBR bearer may be invalidated and a non-GBR bearer may be provided. Also, from the above description, it is clear that a dedicated bearer with a minimum bandwidth is generated if AvGrBW is not sufficient to carry the traffic of MTC device 300c. In other cases, the appropriate bearer is identified and provided by the service request response message 308c.
  • a dedicated bearer with a minimum bandwidth can be created in various ways. According to the existing bearer new creation process described in Non-Patent Document 2, there is no MME-initiated bearer creation process, but regarding creation of a dedicated bearer with a minimum bandwidth according to the present invention, the MME 302c A bearer generation request may be triggered for the P-GW 303c by using a new signaling process. The MME 302c can send some special trigger to the P-GW 303c, and the P-GW 303c can start the dedicated bearer generation process of P-GW startup.
  • This minimum bandwidth dedicated bearer is a dedicated bearer and a non-GBR bearer that provides the minimum QoS parameters.
  • the P-GW 303c may perform traffic shaping on this minimum bandwidth dedicated bearer. First, it is necessary to notify the PCRF of the violation of G-AMBR.
  • the MTC device 300c uses the minimum bandwidth dedicated bearer and is essentially similar to control traffic. Send application traffic.
  • the response message 308c includes a back-off timer, it is interpreted that only a dedicated bearer with a minimum bandwidth for transmitting the warning message is permitted while the timer is valid. . That is, when the expiration date of the timer expires, it is determined that a normal bearer can be generated, and a service request for high priority / broadband is transmitted.
  • the EPS bearer identifier for this minimum bandwidth dedicated bearer is transmitted by message 308c.
  • Such a U-plane warning message transmitted to the MTC server 304c is indicated as a message 309c.
  • the MTC server 304c Upon receipt of this U-plane warning message 309c, the MTC server 304c begins the process of identifying the traffic of other MTC devices that are not considered to be involved in high priority or important traffic within the group.
  • the MTC server 304c identifies the MTC device 301c as a device that transmits unimportant traffic.
  • the MTC server 304c has sufficient intelligence to identify unimportant traffic, and as a result, the MTC server 304c transmits an application layer message to the MTC device 301c to stop transmission.
  • Such a transmission stop message is shown as message 310c.
  • the MTC server 304c specifies that the MTC device 301c has stopped transmission
  • the MTC server 304c further transmits a transmission ready (CTS) application message to the MTC device 300c using a dedicated bearer with a minimum bandwidth.
  • CTS transmission ready
  • the MTC device 300c By removing one MTC device 301c so that it does not share the group bandwidth, it is possible to secure a sufficient bandwidth for another MTC device 300c.
  • there is no other MTC device that can be requested to stop transmission that is, other MTC devices in the group are also transmitting high priority traffic
  • the MTC device 300c needs to wait for the bandwidth to be released.
  • the MTC server 304c has a bit rate monitoring function that can be used to determine transmission of a CTS to the MTC device 300c.
  • the MTC device 300c When the MTC device 300c receives the transmission ready message 311c, the MTC device 300c does not generate a completely new request for the new GBR bearer, but performs an additional determination process requesting to change the bearer of the dedicated bearer with the minimum bandwidth. Trigger. Such a bearer change process is performed in order to acquire the bandwidth required for the GBR bearer. According to the standard processing related to bearer creation and change described in Non-Patent Document 2, the generation of a dedicated bearer can be executed only by the P-GW 303c. Therefore, it is most appropriate for the MTC device 300c to initiate the bearer change process for the minimum bandwidth dedicated bearer.
  • a bearer change request that requests a dedicated bearer with minimal bandwidth is indicated by a signaling message 312c sent to the MME 302c.
  • the bearer change request is a NAS message.
  • the MME 302c When the MME 302c receives the bearer change request from the MTC device 300c, the MME 302c appropriately responds to the bearer change request based on the current available group bandwidth state 313c.
  • the state 313c reflects the appropriate AvGrBW so that the high priority traffic of the MTC device 300c can be transmitted.
  • the P-GW 303c notifies the MME 302c of AvGrBW information.
  • the MME 302c transmits a positive acknowledgment message to the bearer change request 312c.
  • Such an acknowledgment message is indicated by a signaling message 314c.
  • the bearer change for the dedicated bearer with the minimum bandwidth may be executed in the P-GW 303c and notified to the MME 302c, or may be executed in the MME 302c and notified to the P-GW 303c.
  • the MTC device 300c When the MTC device 300c receives an appropriate bearer change for the dedicated bearer with the minimum bandwidth from the MME 302c, the MTC device 300c starts transmitting U-plane traffic to the MTC server 304c. Traffic to this MTC server 304c is indicated by message 315c.
  • the MTC device 300c obtains the bandwidth required to send high priority and high bandwidth traffic to the MTC server 304c without adding retry signaling, thereby enabling the present invention. It is possible to achieve the purpose.
  • the required bandwidth is obtained by setting up such a minimum bandwidth dedicated bearer.
  • the derivative example of the above-mentioned solution method is demonstrated in the scenario peculiar to 3GPP, these derivative examples are applicable to the system which has the same operation
  • the CTS message from the MTC server need not be sent to the MTC device. Rather, when the P-GW detects a state change to AvGrBW, it sends a bearer change request to the MME so that the MME can determine whether the bandwidth required for the MTC device has been released by the MTC server. When the MME determines that the bandwidth is released, the MME passes the bearer change message transmitted from the P-GW to the MTC device.
  • the MTC device 400 normally transmits U-plane traffic to the MTC server 404 via the P-GW 403. Assume that the MTC device 401 is transmitting U-plane traffic to the MTC server 404, and the MTC device 400 is in the idle mode. In addition, it is assumed that the MTC devices 400 and 401 perform group-based communication with the MTC server 404 and have an upper limit on the group bandwidth. In addition, since all assumptions of the operation in the description of the present invention are applied and the details and assumptions of the operation are as described above, description thereof is omitted here.
  • the MTC device 400 can transmit a service request message with a high-priority traffic transmission trigger added as shown in the message 406.
  • MME 402 uses state 407 to determine that no available group bandwidth that meets the traffic requirements of MTC device 400 is available.
  • the MME 402 determines the minimum bandwidth bearer, and preferably notifies the bearer identifier of the minimum bandwidth bearer through a service request response message 408.
  • the MTC device 400 then sends an urgent traffic warning to the MTC server 404.
  • This message (PAM: Priority Alarm Message) is indicated by a message 409.
  • the MTC server 404 checks whether the MTC device 400 can be excluded from group bandwidth sharing.
  • the MTC server 404 communicates with the P-GW 403 to obtain the bit rate associated with the MTC device 400 and checks which devices need to be excluded from group bandwidth sharing. Note that the exchange between the MTC server 404 and the P-GW 403 can be performed using the interface 412. Since the MTC server 404 communicates with the P-GW 403, an application protocol interface (Application Protocol Interface: API) is required between the P-GW 403 and the MTC server 404. The checking process when the MTC server 404 determines to identify the MTC device that needs to be discontinued is indicated by state 410. When the MTC server 404 identifies such an MTC device 400, the MTC server 404 transmits a transmission stop message 411 to the MTC device 401.
  • API Application Protocol Interface
  • the MTC server 404 does not transmit a CTS message to the MTC device 400.
  • the MME 402 assists in the notification process to initiate transmission of high priority and high bandwidth traffic to the MTC device 400.
  • the MTC device 401 stops transmission, the state of AvGrBW in the P-GW 403 is changed, and the value of AnGrBW increases in the P-GW 403.
  • the P-GW 403 transmits the bearer change signaling 413 to the MTC device 400 using the bearer change process as described above.
  • the MME 402 examines these bearer change signaling 413 and determines whether AvGrBW is sufficient to cause the MTC device 400 to forward high priority and broadband traffic. Such determination processing is the same as that described above, and a description thereof is omitted here.
  • the MME 402 determines that the MTC device 400 can start the service, the MME 402 passes an associated bearer change message to the MTC device 400 regarding the bearer that the MTC device 400 is supposed to use. Alternatively, if there is only a minimum bandwidth dedicated bearer, the MME 402 passes a bearer change message associated with this minimum bandwidth dedicated bearer to the MTC device 400.
  • the bearer change signaling message sent from the MME 402 to the MTC device 400 is indicated by signaling 414.
  • the MTC device 400 may use the notified dedicated bearer for its uplink high priority traffic transmission.
  • the MME 402 notifies only the default bearer to the MTC device 400. Such U-plane traffic transmission is indicated by message 415.
  • the main advantage of this method is that the MTC device 400 does not need to initiate a bearer change process, as illustrated in FIG. As a result, there is an advantage that the battery power of the power-constrained MTC device can be saved. Another advantage is that the MTC device 400 does not have to wait for a CTS message, and the waiting time until a necessary bearer is acquired is small. Another operation of the invention in which an explicit minimum bandwidth bearer is generated is to have a minimum bandwidth dedicated bearer generated and maintained by the network during the initial attach process. Is also possible. Since a dedicated bearer with minimal bandwidth uses very small network resources, it can be considered that this bearer can be generated in advance and maintained in the network without imposing a load on the network. Further, as an advantage of creating a dedicated bearer with a minimum bandwidth in advance, a service request response message such as the message 408 can be transmitted without waiting for a bearer with a minimum bandwidth to be created. Also mentioned.
  • the functional architecture illustrated in FIG. 5 has all the hardware, software, and formware required by the MTC device to implement the invention described above.
  • the functional architecture 500 of the MTC device has functional blocks such as an application layer 505, an IP layer (IP routing layer) 504, an NAS layer 503, an AS layer 502, and a wireless communication layer 501, for example.
  • the functional architecture 500 further includes modules for implementing operations according to the present invention (minimum bearer need estimation module 506, high quality (high priority + broadband). Width) service request trigger module 507, minimum bandwidth bearer change determination module 508, minimum bandwidth bearer change trigger module 509).
  • an appropriate signaling interface for passing information between modules is provided between these functional entities.
  • the NAS layer 503 is mainly used for exchange of NAS signaling between the MTC device and its MME. Such NAS signaling can be used in tracking area update, service request when changing from the idle state to the active state, PDN connection establishment, PDN connection deletion, bearer change processing, attach processing, and detach processing.
  • the AS layer 502 is used for all signaling between the MTC device and the eNB. AS layer 502 signaling is used to establish a radio bearer between the MTC device and the eNB.
  • the AS layer 502 is used for cell selection and cell monitoring functions. User plane traffic from the application layer 505 is transmitted via the IP layer 504, reaches the AS layer 502, and is finally transmitted via the wireless communication layer 501.
  • Interfaces 512, 511, and 510 are used to implement data unit transmission of user plane packets. Similarly, an appropriate interface is used at the NAS layer 503 to carry the NAS message. Such interfaces are the interfaces 514, 510 shown in FIG.
  • the wireless communication layer 501 has a physical layer protocol of the MTC device.
  • the MTC device determines that it has high priority and high bandwidth traffic to send, it triggers a service request with embedded high priority and high bandwidth triggers.
  • the determination to trigger a service request for high priority traffic is performed at module 506.
  • the decision to trigger a service request for high priority traffic may be made based on a trigger from NAS layer 503 or by using a direct interface to application layer 505. For example, when the application layer 505 notifies the module 506 that the MTC device has high priority traffic, it determines that a high bandwidth trigger is needed and a high priority trigger needs to be included in the service request. be able to. When such a determination is made at module 506, control is passed to module 507 through interface 515.
  • Module 507 forms or collects relevant data to be passed to NAS layer 503. This related data may be any data for representing a bit rate, high priority, wide bandwidth traffic, or the like. Module 507 passes control data to NAS layer 503 using interface 516. Further, the module 507 has a function of processing response information from the network regarding bearers with a minimum bandwidth. If the minimum bandwidth bearer is the default bearer and the ID of the minimum bandwidth bearer is unique, the MTC device processes this information and changes the QoS internally. Such a function is also associated with the module 507.
  • the NAS layer 503 generates a service request message in which high-priority traffic is inserted into a new information element, and transmits a service request for high-priority traffic through the AS layer 502 and the wireless communication layer 501.
  • the MTC device receives a CTS from the MTC server.
  • the application layer 505 sends a trigger to the module 508 to notify that the bearer change process for the bearer with the minimum bandwidth can be triggered.
  • Processing of a CTS reception trigger from the application layer is executed in module 508.
  • control is passed to the module 509 through the signaling interface 518.
  • a trigger decision is made and the NAS layer 503 is requested to send a bearer change for a dedicated layer with minimal bandwidth.
  • the trigger from the module 509 to the NAS layer 503 is executed via the signaling interface 517.
  • step 600 the check process 600 is triggered and the mobile device (which may be an MTC device) checks whether a high bandwidth and bearer is required to forward high bandwidth traffic. Such a check is performed at step 600.
  • This step 600 identifies whether high priority and broadband traffic needs to be transmitted. If step 600 is “NO”, step 601 is executed. Step 601 has a normal process of triggering a normal service request without adding new information elements to notify high priority traffic and high bandwidth traffic. If step 600 is “Yes”, step 602 is executed. In step 602, a service request with new information regarding high priority traffic is created and transmitted.
  • step 602 After executing step 602, the decision process is triggered. This decision process is indicated by step 603. In step 603, it is checked whether a service request with a high priority trigger has been accepted. Although very rarely occurs, if a service request for a minimum bandwidth bearer is not accepted to obtain bandwidth for high priority traffic, control is passed to step 604; The MTC device decides to retry the service request later.
  • step 603 If step 603 is “yes” and the MME provides a bearer with a minimum bandwidth through a service request response, control passes to step 605.
  • the MTC device reduces the QCI for the bearer if given a default bearer and sends a warning message to the MTC server using the minimum bandwidth bearer.
  • the MTC device waits for the CTS from the MTC server, and executes a CTS reception state check process as shown in step 606.
  • step 608 Upon receipt of the CTS, step 608 is performed and the MTC device requests to increase the QCI for the minimum bandwidth using the device-initiated bearer change process.
  • step 606 if step 606 is “No”, step 607 is executed and the MTC device simply keeps waiting for the CTS or uses the available bandwidth to send information related to emergency traffic to the MTC server. Send.
  • the derivation of the present invention is used to expand performance in configurations where the core network implements Time Controlled and the MTC device has a time-tolerant application.
  • the time control function represents network control related to the access time of the MTC device that uses the network for traffic transmission. If a time control function is present in the network, the MTC device is hardly affected by the time control function when it has a Time Tolerant application. The details of time allowance and time control are described in Non-Patent Document 1.
  • the network When the network is operating a time control mechanism, the network notifies this state to the MTC device, so that the MTC device does not send traffic through the network during the time control period. In most cases, only the MTC device, not the MTC server, knows this time control period. If at the moment the time control period is transmitted, if the network decides to impose time control on the MTC device to the MTC device, the MTC device has no bandwidth and notifies the MTC server about the time control status. Even access to do is not performed. A case where the present invention is applied to such a time-controlled traffic transmission environment will be described with reference to FIG. 7A.
  • the MTC device can notify the MTC server of the congestion state or the time control state in the core network.
  • the MTC server By notifying the MTC server of the congestion state or the time control state, it is possible to prevent the MTC server from transmitting U-plane traffic to the MTC device time-controlled by the network. If the MTC server continues to send traffic to the MTC device in such a time controlled state, it will cause multiple problems for the network.
  • the first problem is the storage resources needed for downlink traffic until the time control state is removed.
  • the second problem is that data may be lost due to buffer overflow.
  • the MTC devices 709, 708, 707, and 706 communicate with the MTC server 702 through the P-GW 701. Also, these MTC devices are connected to the eNB 710, the S-GW 704, and the MME 705, and are performing group communication with the MTC server 702. As described above, if the core network 700 and / or the access network 703 is congested, the network may indicate that the MTC device is prohibited from accessing the 3GPP network for U-plane traffic transmission. Notify the device. Further, assume that these MTC devices have time-allowed traffic.
  • the MTC server 702 may not grasp the time control condition, and some control or polling message is transmitted to these MTC devices, and network resources are wasted.
  • the MTC device 709 generates a bearer 711 with a minimum bandwidth in addition to the default bearer 712 when receiving notification of the time control state of such a network. It is possible to make a request to the network.
  • a minimum bandwidth bearer 711 is only for notifying the MTC server of time control or congestion. By using the bearer 711 with the minimum bandwidth, the MTC device 709 transmits a message to the MTC server 702 to notify that it is in a time control state.
  • the MTC server 702 stops sending messages to the MTC device 709 until the time control period expires. If the time control window is static, the window period can be notified to the MTC server 702. On the other hand, in the case of a dynamic time control window period, the network randomly notifies the moment of time control expiration, and the MTC device 709 uses the minimum bandwidth bearer to terminate time control. Is sent to the MTC server 702.
  • the MTC device 709 When the MTC device 709 resumes sending traffic to the MTC server 702, the MTC device 709 performs a mobile device-initiated bearer change process for the minimum bandwidth bearer or requests a new dedicated bearer for later use. Keep the minimum bandwidth bearer in dormant mode.
  • the MTC device 700a communicates with the MTC server 702a using an arbitrary network segment 701a.
  • This optional network segment 701a may be a 3GPP network segment.
  • time control means that the MTC device is prohibited from using the network 701a for a certain period of time.
  • the network may impose time control.
  • the time control information transmitted from the network 701a to the MTC device 700a is indicated by a message 703a.
  • This message 703a may be transmitted using any type of message.
  • the time control message 703a can be transmitted by a paging trigger, service request acceptance, or any NAS message, and is not limited to a specific message.
  • the MTC device 700a Upon confirming this message 703a, the MTC device 700a transmits a service request message 704a to the network 701a in order to acquire a bearer having a minimum bandwidth for communicating with the server (MTC server 702a).
  • the minimum bandwidth bearer request 704a is mainly executed to notify the MTC server 702a of the time control state of the MTC device 700a.
  • the network 701a creates a bearer with the minimum bandwidth as described above, and transmits a response message 705a having the ID of the bearer with the minimum bandwidth to the MTC device 700a.
  • Such a response message to the MTC device 700a and the establishment of the minimum bandwidth bearer are indicated by messages 705a and 706a, respectively.
  • the MTC server 702a is not informed of the period during which time control is imposed.
  • the MTC device 700a transmits a U-plane warning message to the MTC server 702a using a bearer with a minimum bandwidth. .
  • a warning message is indicated by message 707a.
  • the MTC server 702a performs appropriate settings to prevent or interrupt U-plane traffic to the MTC device 700a. This is shown in state 708a.
  • the network 701a makes a decision to relax the time control of the MTC device 700a.
  • the relaxation of time control can be sent by an explicit message 709a.
  • the network 701a knows the time control period in advance, the network 701a transmits the period information by a message 703a. However, in most cases, the network 701a does not know the exact duration of this time control and tries to notify the MTC device 700a by an explicit trigger 709a.
  • the MTC device 700a requests the network 701a to expand the minimum bandwidth bearer for transmitting U-plane traffic to the MTC server 702a.
  • bearer change signaling is indicated by messages 710a, 711a.
  • Uplink data transmission is indicated by message 712a and downlink data message is indicated by message 714a.
  • the first advantage is that the MTC device is more easily switched to the connected mode by such a minimum bandwidth bearer allocation, and as a result, when the MTC server tries to notify the transmission ready information, the MTC is more easily performed.
  • the server will be able to communicate with the device.
  • the MTC device When the MTC device is in connected mode, there is no delay in receiving paging in connected mode, and as a result there is no delay associated with transitioning to connected mode, so it takes almost time to receive a message from the MTC server. I don't need it.
  • the second advantage is that since the MTC device can be reached from the MTC server in the connected mode, paging signaling from the network and service request signaling from the MTC device can be avoided.
  • a third advantage is that the MTC device uses a U-plane warning message to notify the MTC server, so this message can be another means (other than bandwidth messages) or using hop-by-hop forwarding to the MTC server. It is possible to transmit to the MTC server in a shorter time.
  • the MTC device may indicate its current emergency status using control plane signaling. It may be beneficial to notify the MTC server and remain idle. In general, when the MTC device is in the idle mode, the frequency of location update is low, and it is not necessary for the MTC device to perform cell monitoring for handoff management. According to a preferred embodiment of the present invention, the warning message regarding the lack of bandwidth or the time control state is notified to the MTC server by a control plane message.
  • the MTC device sends a control plane message to the network to notify the MTC server from the network that the bandwidth is insufficient or is in a time control state.
  • a control plane message to notify the MTC server from the network that the bandwidth is insufficient or is in a time control state.
  • the interface between MTC device and network In addition, the packet size of the control plane message is smaller than that of the U plane message.
  • the layered protocol architecture increases the size of the U-plane message. Therefore, it is useful to inform the network of the warning status of the MTC device using control plane signaling under bandwidth constrained environment. Further, the signaling exchange of the present invention will be described with reference to FIG.
  • the MTC device 800 communicates with the MTC server 802 via the network segment 801.
  • the network segment 801 may be a 3GPP network, but is not limited to a 3GPP network.
  • the MTC device 800 may attempt to transmit high priority, wide bandwidth, real time U-plane traffic to the MTC server 802. It is assumed that the MTC device 800 is currently in an idle mode and transmits a service request message 803 to the network 801 in order to transmit this high priority traffic. Further, it is assumed that the value of AvGrBW is 0 when the message 803 is received by the network 801. Note that the network 801 may determine to impose time control on the MTC device 800 when the message 803 is received. In the network conditions described above, the network 801 can send a service request rejection message 804 with appropriate items. This rejection item, for example, informs the network that the reason for rejection is either AvGrBW is not sufficient or time-controlled active in the network 801.
  • the MTC device 800 When the MTC device 800 receives the message 804, the MTC device 800 recognizes that there is no bearer reaching the MTC server 802 using the U-plane message, and remains in the idle mode. In addition, after receiving the rejection item of the message 804, the MTC device 800 performs determination processing and determines to transmit a C plane message to the network 801.
  • This C-plane message is a request to notify the MTC server 802 of the state of the MTC device 800.
  • the C plane message may be a TAU when the network 801 is a 3GPP network, or may be an arbitrary NAS message.
  • the message 805 also includes information regarding the necessity for such status information to be passed to the MTC server 802.
  • the network entity 801 receives the control message 805 and sends another new control message 806 to the MTC server 802.
  • the control message 806 includes state information of the MTC device 800. Note that the message 806 does not have to be transmitted via the core network connecting the network 801 and the MTC server 802, and the message 806 can be transmitted through another network.
  • the MTC server 802 attempts to obtain some available bandwidth for the MTC device 800 as described above. .
  • the MTC server 802 can transmit the CTS message 807 to the MTC device 800. Since the radio bearer is not allocated by the network 801 when the MCT device 800 makes a previous service request and is in the idle mode, the network 801 transmits a paging message 808 to the MTC device 800.
  • the MTC device 800 Upon reception of the paging message 808, the MTC device 800 transmits a service request message 809 and shifts to the connection mode. Once the service request 809 is accepted, the MTC device 800 transitions to connected mode and all radio bearers are set up, the MTC device 800 can receive a CTS message 807 buffered in the network 801. .
  • the network 801 transmits a service request acceptance message 810 to the MTC device 800.
  • This service request acceptance message 810 may comprise a notification regarding the availability of high priority, high bandwidth, and appropriate bandwidth for transferring real-time traffic. Accepting the service request means that the radio bearer is set up for the MTC device 800.
  • a CTS message 807 is transmitted to the MTC device 800 through a radio bearer.
  • the MTC device 800 can transmit U-plane traffic to the MTC server 802 using an appropriate bearer. Note that transmission of U-plane traffic to the MTC server 802 is indicated by a message 811.
  • the network 801 can also transmit a paging message without waiting for the CTS message 807.
  • the MTC device 800 can send a warning message regarding emergency traffic by inserting such a trigger into the service request message 803. If AvGrBW is 0, the warning message with the service request 803 inserted is processed, and then a control plane message is transmitted to the MTC server 802.
  • each functional block used in the description of the embodiment of the present invention is typically realized as an LSI (Large Scale Integration) which is an integrated circuit. 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.
  • LSI Large Scale Integration
  • IC Integrated Circuit
  • system LSI super LSI
  • ultra LSI 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 and setting of circuit cells inside the LSI may be used.
  • the present invention relates to a communication technique in a packet-switched data communication network.
  • the present invention is particularly applicable to a technique in a group-based communication in which a bandwidth upper limit (group bandwidth upper limit value) is set for a group.
  • the present invention is particularly applicable to machine-to-machine communication and machine type communication technologies.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

　グループベースの通信においてグループ帯域幅に上限がある場合であっても、高優先度及び高帯域幅のユーザプレーントラフィックを送信する必要があるデバイスからそのユーザプレーントラフィックを送信できるようにする技術が開示され、その技術によれば高優先度及び高帯域幅のユーザプレーントラフィックを送信しようとするＭＴＣデバイスがネットワークノード（Ｐ－ＧＷ２１３ａ）にサービス要求を行ったとき、グループ帯域幅の上限値を超えてしまう場合には最小限の帯域幅のベアラの使用を許可する。ＭＴＣデバイスは、このベアラを経由してＭＴＣサーバ２１４ａへトラフィックの送信要求を行う。ＭＴＣサーバは、適切な他のＭＴＣデバイスのトラフィックを停止させて、高優先度及び高帯域幅のユーザプレーントラフィックを有するＭＴＣデバイスのために、帯域幅を確保する。

Description

通信装置、ネットワークノード並びに通信サーバ
　本発明は、パケット交換型データ通信ネットワークにおける通信技術に関する。具体的には、本発明は、あるグループに属し、グループ帯域幅上限値に関連する帯域幅制約を有する通信装置と、ネットワークを構成するネットワークノード及び通信サーバに関する。
　セルラ通信は、Global System for Mobile Communications（ＧＳＭ）ネットワークの黎明期から、General Packet Radio Service（ＧＰＲＳ）、そして現在世界中で利用されているUniversal Mobile Telecommunications System（ＵＭＴＳ）へと継続して発展している。近い将来、次世代Long Term Evolution（ＬＴＥ）ネットワークが利用可能となるであろう。また、アクセス技術と共に、セルラ通信ネットワークによって提供されるサービスも発展してきている。現在のセルラネットワークは、初歩的な音声通話サービスだけを提供するものではなく、短いテキストメッセージの伝送やグローバルインターネットへのアクセスも提供している。また最近、例えばマシントゥーマシン（Ｍ２Ｍ：machine-to-machine）通信などのノンヒューマン（non-human）コミュニケーションをカバーするための新たなサービスへと拡張してきている。また、第３世代パートナーシッププロジェクト（３ＧＰＰ：the Third Generation Partnership Project）は、セルラネットワークがマシンタイプ通信をサポートするための要件定義を開始している（下記の非特許文献１を参照）。これにより、セルラネットワークは、マシンタイプ通信をより適切にサポートするものとなる。
　Ｍ２Ｍ通信は、ヒューマントゥーヒューマン（Ｈ２Ｈ：human-to-human）コミュニケーションとは異なる通信パラダイムである。Ｍ２Ｍ通信は、通信シナリオ及び通信モデルにおいて異なっている。マシンタイプ通信シナリオのほとんどは、単一又は複数のマシンタイプ通信（ＭＴＣ：Machine Type Communication）デバイスと、単一のＭＴＣサーバとの間の通信に関係する。以下のａ）からｇ）は、ＭＴＣデバイスがＭＴＣサーバへ通信を行うシナリオの一例である。ａ）ＭＴＣデバイスがＭＴＣサーバに対して、人間の健康に関するデータをアップデートする健康管理産業、ｂ）ある会社に属する船舶が、ＭＴＣデバイスを実装する移動中の船舶から送信されるアップデートデータを用いてサーバにより追跡される航路追跡、ｃ）所有物を監視する産業、ｄ）天候に関する情報をサーバにアップデートする天候センサ、ｅ）食料の状態に関する情報をサーバにアップデートする食料センサ、ｆ）停電や電力消費に関する情報をＭＴＣサーバにアップデートする家庭内のスマートメータ、ｇ）侵入者の検知情報をＭＴＣサーバへアップデートする監視カメラ。
　また、ＭＴＣサーバがＭＴＣサーバへ通信を行うシナリオに加えて、ＭＴＣデバイス間通信のような別のＭＴＣ通信シナリオも存在する。このような通信シナリオの一例としては、ＭＴＣデバイスを制御し、より良い動作をさせるために、家庭内に配置されているスマートメータ間で通信を行う場合が挙げられる。ヒューマントゥーヒューマンとは異なるＭ２Ｍ通信の特徴は、以下の通りである。ａ）人間の介入や決定処理なく動作する、ｂ）遅延許容性や非常に低いデータアプリケーションなどのような異なる通信トラフィックのタイプを有する、ｃ）モバイルのみが存在するタイプ、データ取得のためのサーバからのポーリングが行われるモデル、一般的なモバイルのタイプなどのような異なる通信モデルを有する、ｄ）モビリティが低いパターンやモビリティの無いパターンなどのように、ＭＴＣデバイスに対して異なる位置管理動作を行うような異なるモビリティパターンを有する、ｅ）単一のメッセージを使用して複数のＭＴＣデバイスに到達可能とするグループベースのアドレッシングなど、異なるアドレッシング機構を有する、ｆ）人間によって制御されないＭＴＣデバイスによって窃盗や破壊行為を防ぐ必要性を有する、ｇ）あるサービス加入の下で配置されている複数のＭＴＣデバイスによって、グループベースの課金やサービス提供モデルを有する、ｈ）より廉価な動作のために電力ラインが供給がされておらず、ほとんどのＭＴＣデバイスをバッテリ駆動式とすることによって極力電力消費を抑えた動作を有する。このようなＭ２Ｍに具体的に関連するユニークな特性は、サービス要件を特定してネットワークの最適化を実現するために使用される。３ＧＰＰコアに接続しているＭＴＣデバイスの数は、３ＧＰＰに接続している従来のユーザ端末（ＵＥ）よりもずっと多く、マシンタイプ通信のユニークな特性をターゲットとするネットワーク最適化を有することが不可欠である。その結果、ネットワークオペレータは、動作コストを大きく低減させ、ＭＴＣデバイスに関連する魅力的な課金モデルを提供することが可能となる。
　ＭＴＣデバイスのユニークな特性に関して具体的に実装されるネットワーク最適化を提供するためのサービス及びアーキテクチャ要件を画策するため、３ＧＰＰのＳＡ１（Service Aspects 1）及びＳＡ２（Service Aspects 2）ワーキンググループにおいて標準化が行われている。ＭＴＣデバイスに関連するサービス要件及びネットワーク最適化は、例えば、下記の非特許文献１に開示されている。非特許文献１に開示されているＭＴＣ関連のサービス要件の多くは、ＭＴＣ通信のためのネットワークを最適化すること、又はネットワークを改善することをターゲットとしている。非特許文献１には、単一の加入者に属し、ＭＴＣサーバと通信を行っているＭＴＣデバイスのグループに対して、帯域幅の上限が課されるというサービス要件が開示されている。ここでは、このようなグループ向けの帯域幅の上限を、グループ全体最大ビットレート（group bandwidth maximum bit rate：Ｇ－ＡＭＢＲ）と呼ぶことにする。この非特許文献１では、帯域幅に関連するすべてのパラメータは、ビット／秒の単位で表されている。Ｇ－ＡＭＢＲは、アップリンク、及び／又は、ダウンリンクに関して独立して割り当て可能である。なお、アップリンクＧ－ＡＭＢＲは、ＵＬ－Ｇ－ＡＭＢＲと記載し、ダウンリンクＧ－ＡＭＢＲは、ＤＬ－Ｇ－ＡＭＢＲと記載する。ユーザプレーン（Ｕプレーン）トラフィックが主にアップリンクであるＭ２Ｍグループ通信モデルでは、ＵＬ－Ｇ－ＡＭＢＲのみが適用されてもよい。また、ダウンリンクが支配的な場合も同様に、ＤＬ－Ｇ－ＡＭＢＲのみが適用されてもよい。Ｇ－ＡＭＢＲが適用されている場合、グループに属する多数のＭＴＣデバイスが行っているユーザプレーントラフィックに関するトータルの帯域幅が、いかなるときでもＧ－ＡＭＢＲを超えることはできない。このようなグループの上限を超えると、実施ポイント（帯域幅の使用状況をチェックするポイント）においてトラフィックのシェーピングが行われる。上述のグループベースの通信モデルでは、すべてのＭＴＣデバイスが同一のサーバと通信を行っているので、すべてのＭＴＣデバイスは、同一のパケットデータネットワークゲートウェイ（packet data network gateway：Ｐ－ＧＷ）を利用し、その結果、トラフィック実施ポイントはＰ－ＧＷとなる。このＧ－ＡＭＢＲを割り当てるための主要な動機は、グループ内のすべてのＭＴＣデバイスが同時にコアネットワークを使用する際に必要とされるトータルの帯域幅より小さい値のＧ－ＡＭＢＲを設定することである。
　ネットワークによってＧ－ＡＭＢＲの上限値が割り当てられることは、グループベースの通信において合理的である。切り詰められえたグループ帯域幅の上限値を用いることによって、加入者は、オペレータに支払うサービス料が少なくなる。さらに、オペレータは、多くのＭＴＣデバイスをネットワークに収容することができ、魅力的な価格を提供することでより多くの収入を得ることができる。また、Ｇ－ＡＭＢＲは、通常は、home subscription server（ＨＳＳ）によって割り当てられる静的な値であるか、又は、Ｐ－ＧＷに静的に格納されているか、又は、policy control and charging related function（ＰＣＲＦ）からＰ－ＧＷへ静的な方法で提供されるものである。しかしながら、Ｇ－ＡＭＢＲは、ＰＣＲＦによって動的に管理可能な動的な値であってもよい。また、下記の非特許文献２には、上述した機能エンティティの機能上の役割が詳細に説明されている。
　Ｇ－ＡＭＢＲの概念を用いることによって、上述のような利益が多数提供されるが、トレードオフ、すなわち、不利益も存在している。例えば、Ｇ－ＡＭＢＲの上限によって、グループの複数のＭＴＣデバイスの間で現在使用されている帯域幅がＧ－ＡＭＢＲに達しており、かつ、そのグループの別のＭＴＣデバイスがユーザプレーントラフィックを送信しようとした場合に問題が生じる。この場合、このＧ－ＡＭＢＲの上限によれば、複数のＭＴＣデバイスが同時に、限定的に利用可能な帯域幅や自由に使用可能な帯域幅を求める場合も問題が生じる。グループにおいて利用可能な自由な帯域（ここではＡｖＧｒＢＷと記載する）は、（Ｇ－ＡＭＢＲ）－（Ｕプレーントラフィックを送信しているグループ内のＭＴＣデバイスに関する帯域幅又はビットレートの現在の総量）に等しい。なお、ＡｖＧｒＢＷは、ビット／秒で表すことが可能である。
　非特許文献２に概説されているように、通常のＵＥにおける動作によれば、最初のアタッチ処理の間、デフォルトベアラに関連付けられるサービス品質（quality of service）パラメータは、ノンアクセスストラタム（Non Access Stratum：ＮＡＳ）メッセージ（Attach Accept message）によって、mobility management entity（ＭＭＥ）からＵＥへ通知される。最初のアタッチ処理の間に、通常のＵＥへのベアラコンテキストの通知処理に加え、ＵＥが接続モード（Connected Mode）又はアイドルモード（Idle Mode）のとき、ベアラ変更処理（Bearer Modification procedure）を利用してベアラコンテキストの変更がＵＥへ通知される。非特許文献２には、接続モード及びアイドルモードの定義が記載されている。ベアラ変更処理は、ほとんどの場合はＰ－ＧＷによってトリガ可能であり、また、ＭＭＥによってトリガされる場合もある。上述した通常のＵＥの処理の説明から、ＵＥは、ベアラコンテキストを事前に把握する必要があり、これによって、適切な特性を有するアップリンクＵプレーントラフィックを送信することができ、ダウンリンクＵプレーントラフィックを受信することができるようになることは明らかである。また、リソース管理や３ＧＰＰ evolved packet system（ＥＰＳ）のＱｏＳモデルに違反するものでもない。例えば、ネットワークがある帯域幅に関連したパラメーターをベアラ（例えば、専用ベアラ（dedicated bearer：個別ベアラ））へ割り当てた場合、ＵＥは、それに応じて、Ｕプレーントラフィックの伝送速度を調整しなければならない。また、ネットワークが、ＵＥに関連するすべての非ＧＢＲ（Guaranteed Bit Rate）フローのための最大帯域幅（ＵＥ－ＡＭＢＲ）、あるいは、ＵＥのアクセスポイントネーム（access point name：ＡＰＮ）に関係するすべての非ＧＢＲフローのために最大帯域幅（ＡＰＮ－ＡＭＢＲ）を割り当てている場合には、ＵＥは、そのフローに関係する帯域幅がネットワークによって課せられた上限の総計を超えないようにしなければならない。事前にベアラ特性を把握する重要な利点として、ＵＥがアイドルモードから接続モードへ状態を変更したときに、Ｕプレーントラフィック伝送が迅速に開始できるという点がさらに挙げられる。これにより、ＵＥは、Ｕプレーントラフィックを送信する前に、ベアラコンテキストを把握するための時間を待機する必要がなくなる。
　ベアラに関係するＱｏＳパラメータは、例えば、ＱＣＩ（quality class indication）、ＡＲＰ（allocation and retention priority）、ＭＢＲ（maximum bit rate）、ＧＢＲ（guaranteed bit rate）などである。また、このようなＱｏＳパラメータに加えて、例えば、ＵＥ－ＡＭＢＲやＡＰＮ－ＡＭＢＲなどの非ＧＢＲベアラのためのグループＱＯＳパラメータも割り当てられる。これらのＱｏＳパラメータの詳細な説明及び定義は、非特許文献２に明確に開示されている。すべてのパケットデータネットワーク（packet data network：ＰＤＮ）コネクションに関して、必要最小限のデフォルトベアラが作成される。このデフォルトベアラには、最小限のＱｏＳパラメータ（最低限のＱｏＳ処理を必要とするＱＣＩ値）が割り当てられる。このベアラは、通常は非ＧＢＲベアラである。ＱｏＳパラメータであるＭＢＲ及びＧＢＲはＧＢＲベアラにのみ関係するので、デフォルトベアラに対しては、ＱｏＳパラメータであるＭＢＲ及びＧＢＲは割り当てられない。また、非特許文献２に開示されているように、専用ベアラは、通常、Ｐ－ＧＷが開始するベアラ生成要求処理（P-GW initiated create bearer request procedure）によって生成される。専用ベアラは、ＧＢＲベアラであってもよく、非ＧＢＲベアラであってもよい。ＧＢＲベアラである専用ベアラがネットワークによって割り当てられると、ネットワークは、無線アクセスネットワーク（radio access network：ＲＡＮ）及びコアネットワークにおいて適切なリソース予約処理を用いることで、ＧＢＲベアラのビットレートが確実に保証されるようにする。
　ネットワークは専用ベアラのための帯域幅を保証するが、リソースが利用不可能な場合などには、いつでも専用ベアラのＧＢＲを変更することができる。なお、現在のＵＥの処理において、この専用ベアラの変更はほとんど起こらず、専用ベアラ変更をＵＥへ事前に通知する。同様に、ＵＥのＵＥ－ＡＭＢＲ及びＡＰＮ－ＡＭＢＲも、ほとんど変更されず、これらの情報は、非特許文献２に概説されているＱｏＳ変更なしのベアラ変更処理を利用してＵＥへ通知可能であると仮定されている。例えば、ＵＥがアイドルモードの場合には、ベアラコンテキストの変更は最初のページングによって通知され、これにより、ＵＥは、サービス要求（Service Request）処理を実行する。ＵＥがサービス要求の実行に成功すると、変更されたベアラコンテキストがＵＥへ渡される。しかしながら、現在のＵＥは、ＭＴＣデバイスのような低電力要件を有していないため、ページングされてベアラ変更を受信するために起動されたとしても、電量を消耗していまうという重大な問題が生じるわけではない。さらに、通常のＵＥに関しては、ネットワークは、リソース管理を懸念する必要はほとんどなく、ベアラ変更はほとんど生じないので、ページング、及び、ページングに伴うシグナリングのコストはあまり高くはならない。例えば、専用ベアラのためのＵＥ－ＡＭＢＲ、ＡＰＮ－ＡＭＢＲ、ＧＢＲが変更される可能性が低い。しかしながら、ＭＴＣデバイスに関しては膨大な台数が存在することを考慮すると、グループ帯域幅上限や効率的なリソース管理に係る特別な技術（非常に大多数のＭＴＣデバイスの接続が必要となるＭ２Ｍ通信を収容するためにネットワークで動作する技術）が存在するとき、ネットワークはより多くのベアラ変更メッセージを送信する。
　また、下記の特許文献１には、第１のデバイスで帯域幅が使用されない場合、第１のデバイスから第２のデバイスへ帯域幅の再割り当てを行う方法が開示されている。ここでは、デバイスはグループ通信を行っていると考えられる。また、特許文献１には、あるデバイスで使用されていない帯域幅を別のデバイスへ移すことによって、効率的な帯域幅の使用を実現する方法が開示されている。
　また、下記の特許文献２には、グループ内の単一のデバイスのみが通信を行えるようにするグループ通信モデルの通信メカニズムを実現する方法が開示されている。この方法では、最初のアクセス制御において優先度が使用される方法によって、優先度のメカニズムがカバーされている。また、サービスを受けるより優先度の高いデバイスを取得するための割り込み優先度もカバーされている。
　また、下記の特許文献３には、アタッチメントの際に認証サーバによって、端末へ通信優先度が割り当てられる方法が開示されている。さらに、割り当てられた通信優先度が認証サーバからルータへ通知されると考えられる。また、端末から送信されるパケットに通信優先度が付加されると考えられる。ルータは、この通信優先度が付加されたパケットを見つけると、特別な方法で処理を行う。さらに、ルータは、通信優先度に基づいて優先度の高い端末のアクセス制御を行う。
　また、下記の特許文献４には、グループデバイスのアドレッシングを適切に行う方法が開示されている。伝送ネットワークには、内部で転送要素を定義するためのフレキシブルなトポロジーが含まれている。各転送要素には、伝送ネットワークに属し、複数の地理的に分配されたポートを有するポートグループが含まれている。ポートグループのポート間では、ポイントトゥーマルチポイントの接続性が定められている。識別子は、プロトコル交換用に、内部及び／又は外部要素に対応する単一の要素として、ポートグループを表している。
米国特許７６０９６３４ 米国特許７４０８９４８ 米国特許公開２００７／０２５８４４０ 国際公開公報ＷＯ２００１／０８６８６３
3GPP TS 22.368 V2.0.0, "Service Requirements for Machine Type Communications", 2010年3月 3GPP TS 23.401 V9.3.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 2009年12月
　しかしながら、グループ帯域幅上限（すなわち、Ｇ－ＡＭＢＲ）が課されており、そのグループのＭＴＣデバイスが、送信すべきデータとして、リアルタイムトラフィック、広帯域幅を要するトラフィック、高優先度なＵプレーントラフィックを有している場合に問題が生じる。ここで説明する主な問題は、ＡｖＧｒＢＷが、ＭＴＣデバイスの広帯域、かつ、遅延耐性の無いトラフィック（例えば、高優先度のリアルタイムビデオキャプチャ情報）を伝送するためには十分ではない場合に基づいている。グループモデルの下で、Ｇ－ＡＭＢＲがＭＴＣデバイスのためのグループＱｏＳパラメータとして使用され場合、ＭＴＣデバイスは、そのグループに関するＡｖＧｒＢＷを把握する必要があるとする。ＭＴＣデバイスがこの値を把握していない場合には、そのアップリンクＵプレーントラフィック伝送を正しく行うことはできない。デバイスは、送信すべきリアルタイムＵプレーントラフィック（例えば、リアルタイムビデオ）を有している場合には、そのＵプレーントラフィック伝送レートをＡｖＧｒＢＷより確実に小さくする必要がある。ＭＴＣデバイスがレート制御を受けてもよい遅延耐性を有するトラフィック（例えば、任意の伝送レートで送信可能なデータトラフィック）を有している場合には、ＭＴＣデバイスは、ＡｖＧｒＢＷを把握して、そのアプリケーショントラフィックレートをＡｖＧｒＢＷに応じて変更できるようにする必要がある。
　さらに、上述の問題について、図１を参照しながら説明する。ＭＴＣデバイス１０３、１０４、１０５、１０６はグループに加入しており、ほとんどの場合、コアネットワーク（３ＧＰＰ ＥＰＣ）１００を通じてＭＴＣサーバ１０２と通信を行う。ＭＴＣデバイスの１つ（例えば、ＭＴＣデバイス１０６）がＭＴＣサーバ１０２と通信を行う場合、Ｐ－ＧＷ１０１は、Ｕプレーンのアップリンクトラフィックのレートを監視して、ＭＴＣデバイス１０６に関連する帯域幅を把握する。図１で、ＭＴＣデバイス１０６からのアップリンクＵプレーントラフィックはメッセージ１１０として示される。Ｐ－ＧＷ１０１は、（ＵＬ－Ｇ－ＡＭＢＲ）－（ＭＴＣデバイス１０６からのアップリンクのユープレーントラフィックレート）であるＡｖＧｒＢＷを算出すると、ＱｏＳアップデートを行わないベアラ変更処理（bearer modification procedure without bearer QoS update）を利用して、ＭＴＣデバイス１０３、１０４、１０５、１０６に、ＡｖＧｒＢＷを通知する。一般に、ベアラのＱｏＳをアップデートしないベアラ変更処理は、一般的には、非特許文献２に開示されているように、トラフィックフローテンプレート（ＴＦＴ：traffic flow template）、及び／又は、ＡＰＮ－ＡＭＢＲを変更する際に用いられる。ＭＴＣデバイス１０３、１０４、１０５に向けて送信されるベアラ変更処理に関連するシグナリングは、シグナリングメッセージ１０７、１０８、１０９のそれぞれによって示される。ＭＴＣデバイス１０３のみが、アップリンクＵプレーントラフィックをＭＴＣサーバ１０２に送信予定であるならば、ＭＴＣデバイス１０４、１０５へのベアラ変更シグナリングは、無駄なシグナリングである。Ｍ２Ｍの構成及び動作においては、シグナリングオーバヘッドが発生してしまうので、シグナリングメッセージ１０８、１０９によって示されているベアラ変更シグナリングの追加は望ましくない。ＡｖＧｒＢＷを伝送するベアラ変更シグナリングで伝送される情報を必要としないＭＴＣデバイスがグループ内に多数存在する場合には、ベアラ変更シグナリングは、コアネットワークのリソースを浪費してしまうことになる。
　さらに、図１に示されているＭＴＣデバイスは低電力であり、ＡｖＧｒＢＷをアップデートするためにＭＴＣ１０４、１０５を不要に起動させることは、電力供給に制限のあるＭＴＣデバイスの電力を浪費してしまうことになる。また、図１に示されているシナリオにおいて、ある時間が経過した後、ＭＴＣデバイス１０３が、送信すべきアップリンクＵプレーントラフィックを有するとする。ＭＴＣデバイス１０３のトラフィックは、リアルタイム、高優先度、広帯域幅であり、遅延させることはできず、また、レートのコントロールもできない。ＭＴＣデバイス１０３に通知されるＡｖＧｒＢＷは、ＭＴＣデバイス１０３が必要とするビットレートをサポートできないものであるとする。ＡｖＧｒＢＷが十分ではないので、高優先度、リアルタイム、広帯域幅トラフィックは、ＭＴＣサーバ１０２に届かない。例えば、ＭＴＣデバイス１０３、１０４、１０５、１０６は、異なるｅＮＤのサービスエリアを渡って様々な地域に配置される監視カメラであるかもしれない。この場合、ＭＴＣデバイス１０３は、侵入者の侵入に関係する重要な情報を送っているかもしれない。こうした重要なメッセージは、リアルタイムで送信される必要があり、侵入者の姿や動作をはっきりとキャプチャするため、広帯域幅が必要である。このように、グループ帯域幅に上限が設定されているモデルにおいて、ＭＴＣデバイス１０３からのＵ－プレーントラフィックが、遅延無くＭＴＣサーバ１０２に到達できるようにすることが必要不可欠である。なお、ここではＭＴＣデバイスによって構成されるグループベースの通信シナリオの問題について説明しているが、当業者であれば、任意のタイプのグループベースの通信に起こる問題であると判断できるであろう。
　また、特許文献１に開示されている技術は、空いている帯域幅（Spare Bandwidth）が存在しない場合に、広帯域幅トラフィックの伝送のために利用可能な帯域幅を取得するものではない。したがって、例えばＡｖＧｒＢＷの状態が必要最小限に設定される場合などにおいて、未使用の帯域幅を再割り当てする方法は、図１で説明した高優先度トラフィックの伝送に係る問題を解決するために利用することができない。
　また、特許文献２に開示されている技術は、グループ内のデバイスに静的な優先度の割り当てが行われていない場合には、高優先度のデバイスのための帯域幅をどのように取得するかが提示されていない。したがって、特許文献２に開示されている技術は、グループ内のデバイスに対して優先度が事前に割り当てられていない場合には、サービスを受けさせる高優先度デバイスを適切に特定することができず、図１で説明した問題を適切に解決することはできない。
　また、特許文献３に開示されている技術によれば、端末から送信されるトラフィックのタイムに基づいて端末の優先度が設定された場合のアクセス制御メカニズムが開示されていない。特許文献３に開示されているように、ネットワークエンティティがデバイスに対して静的な優先度を事前に割り当てた場合には、図１で説明したシナリオのようにネットワークによって優先度の状態が明示的に割り当てられない場合の問題を解決することはできない。さらに、特許文献３には、帯域幅に上限があるケース（図１に図示されているケース）において、どのように高優先度トラフィックが収容されるのかについてカバーされていない。
　また、特許文献４に開示されている技術は、このようなグループ識別子は、通信トラフィックが複数のデバイスへ送信される場合にグループ最適化を実現する適切なメカニズムであるが、図１で説明されている問題を解決するために、ネットワークを通じて高優先度トラフィックを取得する方法を実現することはできない。
　本発明は、上記の問題を解決するため、高優先度、リアルタイム、広帯域幅のユーザプレーントラフィックを有するグループデバイスが存在する場合、利用可能なグループ帯域幅が上記ユーザプレーントラフィックの伝送に十分ではない場合であっても、グループ帯域幅上限の中から必要な帯域幅を取得できるようにすることを目的とする。また、本発明は、デバイスからネットワークへの過度なシグナリングが発生しないよう考慮しながら、デバイスが、電力消費量を抑えつつ、必要な帯域幅を取得できるようにすることを目的とする。
　上記の目的を達成するため、本発明の通信装置は、複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置のそれぞれに割り当てられている通信のビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける通信装置であって、
　高優先度及び高ビットレートのトラフィックの送信を行うかどうか決定する送信決定部と、
　前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した場合、前記高優先度及び高ビットレートのトラフィックの送信を行うためのサービス要求を前記ネットワークへ送信するサービス要求送信部と、
　前記サービス要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックを送信することができないベアラのベアラ識別子を含むサービス要求応答を受信するサービス要求応答受信部と、
　前記ベアラ識別子によって特定されるベアラを経由して、前記高優先度及び高ビットレートのトラフィックの送信要求を前記特定の通信サーバへ送信するトラフィック送信要求部と、
　前記トラフィックの送信要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックの送信が可能かどうかを示す情報を含む送信要求応答を受信するトラフィック送信要求応答受信部と、
　前記送信要求応答から、前記高優先度及び高ビットレートのトラフィックの送信が可能であると判断された場合には、前記高優先度及び高ビットレートのトラフィックを前記特定の通信サーバへ送信するトラフィック送信部とを、
　有する。
　この構成により、高優先度、リアルタイム、高帯域幅のユーザプレーントラフィックを有するグループデバイスが存在する場合、利用可能なグループ帯域幅が上記ユーザプレーントラフィックの伝送に十分ではない場合であっても、グループ帯域幅上限の中から必要な帯域幅を取得できるようになる。また、この構成により、デバイスからネットワークへの過度なシグナリングが発生しないよう考慮しながら、デバイスが、電力消費量を抑えつつ、必要な帯域幅を取得できるようになる。
　また、上記の目的を達成するため、本発明のネットワークノードは、複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置のそれぞれに割り当てられている通信のビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける前記ネットワークを構成するネットワークノードであって、
　前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置から、前記高優先度及び高ビットレートのトラフィックの送信を行うためのサービス要求を受信するサービス要求受信部と、
　前記サービス要求に対する応答として、前記高優先度及び高ビットレートのトラフィックを送信することができないベアラのベアラ識別子を含むサービス要求応答を送信するサービス要求応答送信部とを、
　有する。
　この構成により、高優先度、リアルタイム、高帯域幅のユーザプレーントラフィックを有するグループデバイスが存在する場合、利用可能なグループ帯域幅が上記ユーザプレーントラフィックの伝送に十分ではない場合であっても、グループ帯域幅上限の中から必要な帯域幅を取得できるようになる。また、この構成により、デバイスからネットワークへの過度なシグナリングが発生しないよう考慮しながら、デバイスが、電力消費量を抑えつつ、必要な帯域幅を取得できるようになる。
　また、上記の目的を達成するため、本発明の通信サーバは、複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置のそれぞれに割り当てられている通信のビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける通信サーバであって、
　高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置から、所定のベアラを経由して前記高優先度及び高ビットレートのトラフィックの送信要求を受信するトラフィック送信要求受信部と、
　前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置以外の通信装置のうち、トラフィックの送信を中止させることができる特定の通信装置に対して、トラフィックの中止指示を送信するトラフィック中止指示部と、
　前記トラフィック中止指示部によってトラフィックの送信が中止された特定の通信装置に割り当てられていた帯域幅を、前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置によるトラフィック用に予約し、前記トラフィックの送信要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックの送信が可能であることを示す情報を含む送信要求応答を送信するトラフィック送信要求応答送信部とを、
　有する。
　この構成により、高優先度、リアルタイム、高帯域幅のユーザプレーントラフィックを有するグループデバイスが存在する場合、利用可能なグループ帯域幅が上記ユーザプレーントラフィックの伝送に十分ではない場合であっても、グループ帯域幅上限の中から必要な帯域幅を取得できるようになる。また、この構成により、デバイスからネットワークへの過度なシグナリングが発生しないよう考慮しながら、デバイスが、電力消費量を抑えつつ、必要な帯域幅を取得できるようになる。
　本発明は、上記の構成を有しており、高優先度、リアルタイム、高帯域幅のユーザプレーントラフィックを有するグループデバイスが存在する場合、利用可能なグループ帯域幅が上記ユーザプレーントラフィックの伝送に十分ではない場合であっても、グループ帯域幅上限の中から必要な帯域幅を取得できるようにするという効果を有している。また、本発明は、上記の構成を有しており、デバイスからネットワークへの過度なシグナリングが発生しないよう考慮しながら、デバイスが、電力消費量を抑えつつ、必要な帯域幅を取得できるようにするという効果を有している。
従来の技術におけるグループベースの通信モデルを示す図 本発明の実施の形態におけるグループベースの通信モデルの構成の一例を示す図 本発明の実施の形態における動作の第１の例を示すシーケンスチャート 本発明の実施の形態における動作の第２の例を示すシーケンスチャート 本発明の実施の形態における動作の第３の例を示すシーケンスチャート 本発明の実施の形態における動作の第４の例を示すシーケンスチャート 本発明の実施の形態における動作の第５の例を示すシーケンスチャート 本発明の実施の形態におけるＭＴＣデバイスの構成の一例を示す図 本発明の実施の形態におけるＭＴＣデバイスの処理の一例を示すフローチャート 本発明の実施の形態におけるグループベースの通信モデルの構成の別の一例を示す図 本発明の実施の形態における動作の第６の例を示すシーケンスチャート 本発明の実施の形態における動作の第７の例を示すシーケンスチャート
＜発明の基本原理＞
　本発明は、モバイルデバイスのグループ（例えば、ＭＴＣデバイスのグループ）が、単一又は複数のサーバ（例えば、ＭＴＣサーバ）との間でグループ通信を行っており、そのグループの所定デバイスの高優先度、広帯域幅、リアルタイムのＵプレーントラフィックに利用可能なグループビットレート又はグループ帯域幅を有していない場合に適用される。本発明の基本原理は、このような高優先度のＵプレーントラフィックを有するデバイスが、ネットワークへのシグナリング処理を利用してそのトラフィック状態を通知し、利用可能なグループ帯域幅がネットワークに存在しない場合には最小限の帯域幅のベアラを取得することである。このような最小限の帯域幅のベアラを取得した後、このデバイスは、危機的状態であること（すなわち、高優先度のＵプレーントラフィックを送信できないこと）をサーバへ通知し、その結果、サーバは、高優先度のＵプレーントラフィックを有するデバイスが利用可能なグループ帯域幅を取得するために、重要なＵプレーントラフィックを送信していないグループ内の他のデバイスの伝送を中止する。
　すなわち、本発明の主要な原理に関連するステップ又は処理は以下の通りである。
　あるグループのデバイスは、アプリケーションレイヤのトラフィックに関連した自身の優先状態を判断し、ネットワークへの高優先度Ｕプレーントラフィックの伝送を通知する。
　さらに、ネットワーク（３ＧＰＰネットワーク）から与えられた最小限の帯域幅のベアラを利用し、Ｕプレーントラフィック状態及び利用可能なグループ帯域幅がない状態をサーバへ通知する。
　低優先度Ｕプレーントラフィックを有するデバイスの伝送を中止して、高優先度Ｕプレーントラフィックを有しており帯域幅を要求しているデバイス用に帯域幅を確保するために、サーバは、アプリケーションレイヤのインテリジェンスを利用して、グループ内の他のデバイスのＵプレーントラフィック状態を特定し、低優先度のＵプレーントラフィックに使用されている帯域を解放する。
　最後に、重大な遅延無く高優先度Ｕプレーントラフィックを転送できるようにするため、高優先度Ｕプレーントラフィックに必要なグループ帯域幅が利用可能な状態となったことが、高優先Ｕプレーントラフィックを有するデバイスに通知される。
＜本発明の動作シナリオ＞
　以下、本発明の好適な実施の形態に係る本発明の動作シナリオについて詳細に説明する。ここでは、図２Ａを参照しながら、特に３ＧＰＰ構成に関連した動作シナリオについて説明する。なお、当業者であれば、本発明は３ＧＰＰ固有のシナリオに限定されるものではなく、他の動作シナリオに対しても同様に適用可能であることは明白である。例えば、デバイスは、広帯域アクセスメディアや、その他のタイプのアクセスメディア又はネットワークアーキテクチャを通じて、サーバとの間でグループ通信を行うことが可能である。さらに、本発明は、グループ内のデバイスの１つが、グループベースの通信モデルにおけるサーバとして機能する場合にも適用可能である。また、図２Ａに示されているシナリオは、ＭＴＣサーバと通信を行っているＭＴＣデバイスに関するものであるが、本発明が適用されるデバイスのタイプに関する制約はなく、例えばデバイスは、サービスを受けるためにネットワークに接続する機能を有する通常のモバイル端末であってもよい。
　図２Ａにおいて、ＭＴＣデバイス２００ａ、２０１ａ、２０２ａ、２０３ａが、ＭＴＣサーバ２１４ａなどのサーバとの間でグループベースの通信を利用しているとする。さらに、ＭＴＣデバイス２００ａ、２０１ａ、２０２ａ、２０３ａが、関連するエンドポイントへのユーザプレーン及び制御プレーンのトラフィック伝送に、３ＧＰＰコアネットワーク２１２ａを利用しているとする。また、図２Ａに示されているＭＴＣデバイス２００ａ、２０１ａ、２０２ａ、２０３ａのユーザプレーントラフィックは、ｅＮＢからサービングゲートウェイ（Ｓ－ＧＷ）へのトンネリング機構、及び、Ｓ－ＧＷからＰ－ＧＷへの別の独立したトンネリング機構によって、ＭＴＣサーバ２１４ａに到達しているとする。図２Ａに図示されている３ＧＰＰコアネットワーク２１２ａは、非特許文献２に記載されている３ＧＰＰ拡張パケットコア（evolved packet core（ＥＰＣ））であってもよい。また、コアネットワーク２１２ａは、General Packet Radio Service（ＧＰＲＳ）コアネットワークやUniversal Mobile Telecommunication System（ＵＭＴＳ）コアネットワークであってもよく、同様に本発明が適用可能である。なお、図２Ａは、アクセスシステムとしてＬＴＥを用いた場合の構成を示しているが、ＵＭＴＳを用いた場合は、ｅＮＢはＲＮＣ／ＢＳＣ、ＭＭＥはＳＧＳＮ、ＰＧＷはＧＧＳＮに置き換えられる。
　図２Ａに示されているＭＴＣデバイス２００ａ、２０１ａ、２０２ａ、２０３ａは単一の加入者によって配置されており、相互にオーバラップしない独立した領域（あるいは、オーバラップしている領域が一部のみである）に配置されているとする。独立した領域にＭＴＣデバイスを配置することは、ＭＴＣデバイスがそれぞれ独立したｅＮＢサービスエリア又はセルに配置されていることを表している。このような配置は、最も現実的な配置である。これは、すべてのＭＴＣデバイスが同一の領域に配置されるのではなく、ほとんどの場合において、ＭＴＣデバイスがそれぞれ異なる領域から情報を送信するために使用されるからである。しかしながら、領域内に検出すべき多数のマシンタイプのデータが存在しているような稀な場合には、ＭＴＣデバイス間の負荷バランスを目的として、所定の位置に複数のＭＴＣデバイスを配置することも可能である。通常、ＭＴＣデバイスは送信すべきデータがあまり多くないことを考えると、データの収集、処理、ＭＴＣサーバへの伝送のために、ＭＴＣデバイスが独立したオーバラップしない領域内に配置されることが非常に現実的な配置である。
　ＭＴＣデバイスがオーバラップしない配置モデルに基づき、さらに、図２Ａに示されているように、ＭＴＣデバイス２００ａ、２０１ａ、２０２ａ、２０３ａが、ｅＮＢ２０４ａ、２０５ａ、２０６ａ、２０７ａにそれぞれ接続されているとする。さらに、ＭＴＣデバイス２００ａ、２０１ａがＮＡＳメッセージ（トラッキングエリアアップデート、サービス要求）をＭＭＥ２０８ａへ送信しようとするとき、ｅＮＢ２０４ａ及びｅＮＢ２０５ａが、ＭＴＣデバイス２００ａ及びＭＴＣデバイス２０１ａのそれぞれのために、ＭＭＥ２０８ａとの間にＳ１制御プレーンコネクション（Ｓ１－ＭＭＥ、Ｓ１－ＡＰ(Application Protocol)）のセットアップを行う。同様に、ＭＴＣデバイス２００ａ、２０１ａがアイドルモードから接続モードへ変更してサービス要求メカニズムを実行するとき、Ｓ－ＧＷ２０９ａは、ＭＭＥ２０８ａから指示を受けると、ＭＴＣデバイス２００ａ、２０１ａのそれぞれのために、ｅＮＢ２０４ａ及びｅＮＢ２０５ａとの間にＳ１ユーザプレーンコネクション（Ｓ１－ｕ、ＧＰＲＳトンネリングプロトコル（ＧＴＰ）ベアラ）のセットアップを行う。なお、サービス要求及び一般的なＮＡＳシグナリングに関連する動作メカニズムの詳細は、非特許文献２に記載されている。同様の方法で、ＭＴＣデバイス２０２ａ、２０３ａにおいても、ＭＭＥ２１１ａ及びＳ－ＧＷ２１０ａに向かう適切なベアラがセットアップされる。また、ＭＴＣデバイス２００ａ、２０１ａのために、Ｓ－ＧＷ２０９ａからＰ－ＧＷ２１３ａへのＧＴＰベアラ又はＰＭＩＰトンネルがセットアップされ、同様に、ＭＴＣデバイス２０２ａ、２０３ａのためにＳ－ＧＷ２１０ａからＰ－ＧＷ２１３ａへのＧＴＰベアラ又はＰＭＩＰトンネルがセットアップされる。
　図２Ａに示されるように、３ＧＰＰネットワーク内でＭＴＣデバイスがオーバラップしない配置とすることで、あるグループのＭＴＣデバイスが異なるｅＮＢ、ＭＭＥ、Ｓ－ＧＷに接続・管理されているかもしれない。しかしながら、すべてのＭＴＣデバイスが単一のＭＴＣサーバ２１４ａと通信を行っているので、ＨＳＳに格納されている静的なコンフィギュレーションによって、同一のＰ－ＧＷ２１３ａを割り当てることが可能となる。また、Ｐ－ＧＷ２１３ａは、Ｇ－ＡＭＢＲ上限に対する通信状況を確認するエンティティ（Ｇ－ＡＭＢＲの実施ポイント）、ＡｖＧｒＢＷを計算するポイント、ＡｖＧｒＢＷ情報を通知するエンティティ又は配付するエンティティであるとする。
　図２Ａで説明される動作シナリオは、グループ内のすべてのＭＴＣデバイスが異なるｅＮＢに接続しており、その結果、異なるＭＭＥ及びＳ－ＧＷに接続・管理されるかもしれない場合である。しかしながら、本発明は、ＭＴＣサーバと通信を行うグループベースの通信モデルのすべてのＭＴＣデバイスが、同一のｅＮＢ、同一のＭＭＥ、又は、同一のＳ－ＧＷに接続可能であるというシナリオに対しても同様に適用可能である。このようなシナリオでは、Ｇ－ＡＭＢＲの実施ポイントがＰ－ＧＷではなくＳ－ＧＷであってもよい。しかしながら、もしＳ－ＧＷがＧ－ＡＭＢＲの保持を行うとすれば、ＭＴＣデバイスへＡｖＧｒＢＷを通知できるようにするベアラ変更（bearer modification）処理をトリガするための新たな処理が、Ｓ－ＧＷに導入される必要がある。
＜本発明の適用が可能なシナリオ例＞
　本発明の好適な実施の形態に従って、本発明の適切なシナリオ例について説明する。本発明は、このようなグループベースの帯域幅制限を課されているデバイスが、高優先度、広帯域幅、リアルタイムＵプレーンのトラフィックをサーバへ伝送する必要がある実用的な現実のシナリオに適用可能である。特に、本発明は、あるグループに属するデバイスがグループ帯域幅が制約された状態において、サーバへ送信すべき高優先度Ｕプレーントラフィックを有している一方、グループ内の他のデバイスのいくつかが高優先度Ｕプレーントラフィックをサーバへ送信していない場合に適用可能である。なお、この本発明の実施の形態は、Ｍ２Ｍグループベースの通信シナリオに関係するものであるが、本発明の範囲を逸脱することなく、他の多くの非Ｍ２Ｍシナリオに対しても本発明は適用可能である。
　本発明が適用可能なＭ２Ｍグループベースの通信シナリオの一例としては、例えば、ＭＴＣ加入者が、監視カメラを用いて家や事務所における盗難や破壊行為の画像を取得するための複数のＭＴＣデバイスを配備する例が挙げられる。このような配備シナリオでは、盗難防止及び盗難検出のために、監視カメラが、共通のＭＴＣサーバに対してモニタリングしたイベントをアップデートすると考えられる。ＭＴＣ機能を有する監視カメラは電力に制限があり、バッテリ駆動式かもしれない。また、グループ内のすべての監視カメラは、同じタイプのＵプレーントラフィックをＭＴＣサーバへ同時に送信しているわけではないとする。例えば、監視カメラは、侵入者を検出すると、侵入者の顔、挙動や動作を高解像度でキャプチャした高優先度Ｕプレーントラフィックをサーバへ送信しようとするため、広帯域幅が必要となる。所定の監視カメラが高優先度ＵプレーントラフィックをＭＴＣサーバへ送ろうとしている一方、グループ内の別の監視カメラは、家庭や事務所の通常の活動をキャプチャした通常のトラフィックをＭＴＣサーバへ送信しているかもしれない。このように、高優先度Ｕプレーントラフィックを送ろうとしているが現在十分な帯域幅を有していない監視カメラのための最小限の帯域幅ベアラを取得するために、本発明が適用可能である。監視カメラは、利用可能なグループ帯域幅が不足している状態をＭＴＣサーバへ通知するために最小限の帯域幅ベアラを取得すると、最小限の帯域幅ベアラを経由して警告メッセージを伝送することによって、この状態をＭＴＣサーバへ通知する。ＭＴＣサーバは、監視カメラから帯域幅が不足しているという情報を受信すると、他の低優先度のカメラのセッションを解消し、さらに、高優先度の監視カメラに対して帯域を割り当てた後、サービスを開始するよう通知する。
　本発明が適用可能なＭ２Ｍグループベース通信の別のシナリオとしては、例えば、エンターテインメントとして、カメラ機能を有するＭＴＣデバイスがリアルタイムのイベントをキャプチャしてＭＴＣサーバへ報告するよう配置されている例が挙げられる。例えば、これらのＭＴＣデバイスは、人間が介在することなく動作してリアルタイムでイベントをキャプチャし、マルチメディアトラフィックを使用してテレビ放送局に配置されているＭＴＣサーバへイベントを送信する。
　さらに、本発明が適用可能なＭ２Ｍグループベースの別の通信シナリオとしては、例えば、あるグループのＭＴＣデバイスが、人間の健康状態に関するトラフィックをＭＴＣサーバへアップデートしている場合が挙げられる。ＭＴＣデバイスからのトラフィックのストリームには、例えば、人間の鼓動、体温、血糖レベルが含まれ得る。このような場合、あるグループに属する健康監視のためのＭＴＣデバイスに対してグループ帯域幅の上限が課されているならば、本発明の主要な方法を利用して、健康監視のためのＭＴＣデバイスからの高優先度Ｕプレーントラフィックに対してアクセス許可を与えることが望ましい。本発明の方法を適用することによって、著しく遅延させることなく、健康監視デバイスからの高優先度Ｕプレーントラフィックを伝送できるようにすることを目的とする。
＜Ｇ－ＡＭＢＲ実施ポイントによるベアラの処理＞
　ＭＴＣデバイスがＭＴＣサーバとの間でグループベース通信を行っており、各ＭＴＣデバイスに単一又は複数のベアラが割り当てられている場合において、コアネットワークにＧ－ＡＭＢＲが実施及び実装されているときのベアラ管理実行方法について、本発明の好適な実施の形態に従って説明する。通常のＵＥのための一般的なベアラ管理は、例えば、非特許文献２に開示されている。しかしながら、本明細書では、Ｇ－ＡＭＢＲの上限が設定されている場合のベアラ管理処理について説明する。なお、Ｍ２Ｍ通信シナリオにおけるＧ－ＡＭＢＲが存在する場合のベアラ管理について説明するが、当業者であれば、あるデバイスのために単一又は複数のベアラが生成され、かつ、Ｇ－ＡＭＢＲがシステムに設定及び実装されているような任意のグループベースの通信シナリオにおいて、本発明が適用可能であることが分かるであろう。
　例えば、グループの所定のＭＴＣデバイスに対して、デフォルトベアラのみが確立されているのであれば、利用可能なグループ帯域幅（すなわち、アップリンクＡｖＧｒＢＷ）が０であると通知されると、このＭＴＣデバイスは、Ｕプレーンアップリンクトラフィックを送信することができないとする。デフォルトベアラは非ＧＢＲベアラなので、通知される利用可能なグループ帯域幅が０より大きい場合には、このＭＴＣデバイスは、Ｕプレーンアップリンクトラフィックを送信することができるとする。さらに、ＡｖＧｒＢＷの値が変更された場合には常に、ベアラＱｏＳアップデートを行わないベアラ変更処理を使用することによって、利用可能なグループ帯域幅の状態がこのＭＴＣデバイスに通知されるとする。なお、単一のデフォルトベアラに関して説明されている同一の処理は、ＭＴＣデバイスに関して複数のＰＤＮコネクションが存在しており、ＭＴＣデバイスが複数のデフォルトベアラを持っている場合にも適用される。たとえ複数のデフォルトベアラが存在している場合であっても、ＡｖＧｒＢＷは、ベアラＱｏＳアップデートシグナリングではなく、単一のベアラ変更処理を利用して通知される。これは、ＡｖＧｒＢＷが所定のデフォルトベアラに関連したパラメータではなく、ＭＴＣデバイスに関連したパラメータだからである。
　また、例えば、グループ内の所定のＭＴＣデバイスが専用ベアラ及びデフォルトベアラを有しており、すべての専用ベアラが非ＧＢＲベアラである場合には、このＭＴＣデバイスは、所定のベアラ又はベアラＩＤとは無関係に、ＡｖＧｒＢＷの通知を受けるかもしれない。すなわち、ＡｖＧｒＢＷは、ベアラＱｏＳアップデートを行わない単一のベアラ変更処理を使用して通知される。たとえ複数の非ＧＢＲベアラが存在していたとしても、ＭＴＣデバイスへＡｖＧｒＢＷの値を提供するために単一のベアラ変更シグナリングが使用される。これは、すべてのベアラが非ＧＢＲベアラであり、それに関連する帯域幅が存在せず、それ故、ネットワークは単にベアラ識別子に関連付けられていないＡｖＧｒＢＷを通知するだけだからである。このような場合、ＭＴＣデバイスは、ＡｖＧｒＢＷが０より大きいときにはアップリンクＵプレーントラフィックを送信し、ＡｖＧｒＢＷが０のときにはアップリンクＵプレーントラフィックを送信しない。グループ内のＭＴＣデバイスは、ＡｖＧｒＢＷが０より高いと通知された場合に、非ＧＢＲ専用ベアラ又はデフォルトベアラのどちらかを使用してＵプレーントラフィック送信を行うことが可能である。
　また、別のシナリオにおいて、例えば、グループ内の所定のＭＴＣデバイスがデフォルトベアラ及びＧＢＲベアラを有している場合、ＡｖＧｒＢＷの通知は、Ｐ－ＧＷが、各専用（ＧＢＲ）ベアラに関してベアラ変更シグナリングを独立して送信し、各ＧＢＲベアラのための変更された帯域幅を通知する。これは、帯域幅がＧＢＲベアラに関係していることから、ネットワークがＡｖＧｒＢＷをＧＢＲベアラ間で分割し、その結果、各ベアラに関するベアラ変更シグナリングを送信するからである。例えばＡｖＧｒＢＷがｘの場合、Ｐ－ＧＷは、利用可能な帯域幅のほとんどをＧＢＲベアラへ対照的に又は非対称的に配分するため、ＧＢＲベアラのそれぞれに関して複数のベアラ変更処理を実行する。したがって、ＧＢＲベアラが存在するとき、ＧＢＲベアラ間におけるＡｖＧｒＢＷの個々の分配又は割り当てが必要となるので、ベアラ変更シグナリングが大きくなる。一方、複数の非ＧＢＲベアラの場合では、ＡｖＧｒＢＷを通知する単一のベアラ変更シグナリングで十分である。さらに、ＧＢＲベアラに関連してベアラ変更シグナリングが送信されるとき、その処理は、ベアラＱｏＳアップデートを行わないベアラ変更処理とは異なる。ＧＢＲベアラに関しては、ベアラ変更シグナリングがそのベアラのための帯域幅（ＧＢＲ値）を伝送するので、非特許文献２に開示されているように、その処理は、ＱｏＳアップデートを有するベアラ変更処理となる。また、デフォルトベアラに関係するＧＢＲは存在しないので、最低限の帯域幅のみがデフォルトベアラに残される。新しいＧＢＲ値がＭＴＣデバイスへ通知されると、ＭＴＣデバイスは、このＧＢＲ値がトラフィックの伝送に十分かどうかを判断して、関連するＧＢＲベアラ又はデフォルトベアラを選択することが可能となる。
　所定のＭＴＣデバイスに割り当てられるベアラがデフォルトベアラ、ＧＢＲ専用ベアラ、非ＧＢＲ専用ベアラなどの場合には、Ｐ－ＧＷは利用可能なグループ帯域幅、すなわち、ＡｖＧｒＢＷのほとんどをＧＢＲベアラに割り当ててＭＴＣデバイスへ通知し、ＡｖＧｒＢＷのうちの最小限の帯域幅をデフォルトベアラ及び非ＧＢＲベアラへ割り当てる。Ｐ－ＧＷは、ＧＢＲベアラのために複数のベアラＱｏＳ変更処理を実行し、各ＧＢＲベアラに対して割り当てた帯域幅をそれぞれ通知する。デフォルトベアラ及び非ＧＢＲベアラに関しては、Ｐ－ＧＷは、ベアラＱｏＳアップデートを行わない単一のベアラ変更処理を実行し、デフォルトベアラ及び非ＧＢＲベアラのための利用可能な帯域を一括して通知する。そして、ＭＴＣデバイスは、ベアラＱｏＳアップデートを行わないベアラ変更処理で送信された利用可能な帯域幅値を使用して、１つ以上の非ＧＢＲベアラ経由でトラフィックを送信することができる。同様に、ＭＴＣデバイスは、アップリンクトラフィック送信のために関連するＧＢＲベアラを選択する際に、受信した個々のＧＢＲベアラに関するベアラＱｏＳアップデートを使用する。
　また、ＭＴＣデバイスがＵプレーントラフィック伝送の際に帯域幅が保証されているＧＢＲベアラを持っていたとしても、Ｕプレーントラフィックに利用されていないＧＢＲベアラの帯域幅は、ＡｖＧｒＢＷ計算処理における帯域幅として使用されないとする。例えば、利用可能なグループ帯域幅又はＡｖＧｒＢＷを計算する際、最初のステップにおいて、ＭＴＣデバイスのグループにおいて利用されている全体の帯域幅を特定する。この帯域幅は、ＭＴＣデバイスのＵプレーントラフィックに関係する帯域幅である。そのグループで利用されている帯域幅を特定した後、利用可能なグループ帯域幅が特定可能となる。利用されている帯域幅を計算するとき、実際のＵプレーントラフィックに関係する帯域幅のみが利用されている帯域幅として考慮され、利用されていないＧＢＲベアラに関係する帯域幅は考慮されない。利用されていないＧＢＲベアラは、現在Ｕプレーントラフィックを伝送していないＧＢＲベアラである。
　しかしながら、別の通信モデルでは、ＧＢＲベアラは高優先度ベアラであると考えられ、これらのベアラは、たとえＵプレーントラフィックが現在ＧＢＲベアラ経由で伝送されていない場合でも、そのグループで利用されている帯域幅を計算するために利用することが可能である。このような処理を利用することによって、ＧＢＲベアラに関係する帯域幅は、ＵプレーントラフィックがＧＢＲベアラ経由で送信されているが否かによらず、ＧＢＲベアラが許可されているＭＴＣデバイスにとって常に利用可能な状態となる。しかしながら、ＧＢＲベアラのために固定した帯域幅を常に予約しておくことは、効率的なリソース管理モデルではない。それにもかかわらず、あるシナリオでは、ＭＴＣデバイスは、利用可能なグループ帯域幅の計算処理で、利用可能であることが常に示されている帯域幅を有する特別な専用ＧＢＲベアラを確立するようネットワークへ要求することが可能である。このようなベアラを持つことによって、ＭＴＣデバイスは、高優先度トラフィックの伝送のためにこの特別な専用ＧＢＲベアラをすぐに利用することが可能であり、ＡｖＧｒＢＷを考慮する必要はない。
　上述のＱｏＳベアラ管理処理は、特に、３ＧＰＰ ＥＰＳにおけるベアラ管理処理を説明しているが、当業者であれば、Ｇ－ＡＭＢＲを実行する際に説明されているベアラ管理処理が、ＭＴＣデバイスのＵプレーントラフィックがＧＰＲＳコア又はＵＭＴＳコア又はベアラ管理を利用するその他のシステムを伝送する場合においても適用可能であることが分かるであろう。
＜ＡｖＧｒＢＷがＭＭＥに格納されている際の動作＞
　ベアラ変更シグナリングを送信して、Ｕプレーントラフィックの送信を現在予定していないグループ内のすべてのＭＴＣデバイスに対して、ベアラ間におけるＡｖＧｒＢＷ配分を通知することは、上述のように不要なシグナリングであり、ネットワークリソースの浪費である。さらに、ＭＴＣデバイスがアップリンクＵプレーントラフィックを送信する予定がない場合、そのＭＴＣデバイスをアイドルモードから立ち上げてベアラ全体のＡｖＧｒＢＷ配分を通知することは、ＭＴＣデバイスの電力の浪費である。したがって、ＡｖＧｒＢＷ値に変更があった場合には常に、ＭＴＣデバイスの関連ベアラの帯域幅値をＭＭＥへ通知し、ＭＴＣデバイスがＵプレーントラフィックを送信したいと思うまでＭＭＥがそれを格納することが、より良い実施例である。Ｐ－ＧＷは、新しいＡｖＧｒＢＷに関連して変更されたＭＴＣデバイスのベアラ帯域幅を、ベアラ変更処理を利用して通知し、ＭＭＥは、必要となるまではその値をＭＴＣデバイスへ通知しない。以下、本発明の好適な実施の形態に従って、このようなベアラ管理処理について説明する。以下、図２Ｂを参照しながら、本発明の実施の形態において、このようなより良いベアラ管理処理について説明する。
　図２Ｂにおいて、ＭＴＣデバイス２００ｂ、２０１ｂは、ＭＴＣサーバ２０４ｂとの間でグループベースの通信を行っているＭＴＣデバイスのグループに属しているＭＴＣデバイスである。さらに、ＭＴＣデバイス２００ｂ、２０１ｂのために各ｅＮＢによって選定されたＭＭＥが、ＭＭＥ２０２ｂであるとする。さらに、Ｇ－ＡＭＢＲ実施ポイント及びＡｖＧｒＢＷ計算ポイントがＰ－ＧＷ２０３ｂであるとする。さらに、ＭＴＣデバイス２００ｂはアイドルモードである一方、ＭＴＣデバイス２０１ｂは接続モードであり、ＭＴＣサーバ２０４ｂへＵプレーントラフィックを送信しているとする。
　上述のように、ある配置構成において、ＡｖＧｒＢＷ、及び、ＭＴＣデバイス２００ｂのベアラ間におけるＡｖＧｒＢＷの分配は、関連するベアラ変更処理を利用してＭＭＥ２０２ｂへ通知される。しかしながら、ＭＭＥ２０２ｂは、ＭＴＣデバイス２００ｂがアイドルモードであることを知っているので、これらのベアラコンテキストをＭＴＣデバイス２００ｂへ送信せずに、その代わり、ＭＭＥ２０２ｂの格納手段に格納する。
　このような動作シナリオでは、Ｐ－ＧＷ２０３ｂは、シグナリングメッセージ２０５ｂを用いて、ＡｖＧｒＢＷに関係しているベアラであって、ＭＴＣデバイス２００ｂに関連したベアラのベアラ変更メッセージを送信すると考えられる。このメッセージ２０５ｂの内容は、ＭＭＥ２０２ｂに格納され、ＭＴＣデバイス２００ｂへは転送されない。シグナリングメッセージ２０５ｂの送信後、ＭＴＣデバイス２００ｂは、アイドルモードから接続モードへ移行し、サービス要求メッセージ２０６ｂをＭＭＥ２０２ｂへ送信したとする。ＭＭＥ２０２ｂは、ＭＴＣデバイス２００ｂのために格納されているＡｖＧｒＢＷをチェックし、ＡｖＧｒＢＷがＭＴＣデバイス２００ｂにとって十分なのものかどうかを確認することが可能である。ＭＴＣデバイス２００ｂのＡｖＧｒＢＷは、ベアラ変更メッセージ２０５ｂに埋め込まれた帯域幅情報によってＭＭＥ２０２ｂへ通知される。状態２０７ｂに示されているようにＡｖＧｒＢＷが０であれば、ＭＭＥ２０２ｂは、サービス要求応答メッセージ２０８ｂを送信し、適切な項目値（clause）を用いてサービス要求を拒絶することが可能である。なお、項目値は、例えば、ＡｖＧｒＢＷの不足による拒絶とすることが可能である。
　ＡｖＧｒＢＷが０より大きい場合には、ＭＭＥ２０２ｂは、サービス応答処理２０８ｂにおいて、デフォルトベアラや専用ＧＢＲベアラに関係する帯域幅を単に通知し、Ｕプレーントラフィック伝送に関して帯域幅が十分かどうかをＭＴＣデバイス２００ｂに決定させればよい。このような場合、ＭＭＥ２０２ｂは、サービス応答ＮＡＳメッセージ２０８ｂの新たな情報要素によって、ベアラに関連した帯域幅値を通知し、拒絶の項目値によるサービス要求の拒絶は行わない。
　また、ＭＴＣデバイス２００ｂがＵプレーントラフィック伝送に必要なビットレートをサービス要求２０６ｂにおいて送信した場合には、ＭＭＥ２０２ｂは、ＡｖＧｒＢＷの値及びＭＴＣデバイス２００ｂのベアラにおけるＡｖＧｒＢＷの分配に基づいて、サービス受け入れメッセージ又はサービス拒絶メッセージを送信する。要求されたビットレートをサポートする単一のＧＢＲベアラが存在する場合には、ＧＢＲベアラが許可されて、サービス要求応答メッセージ２０８ｂによってベアラ識別子が通知される。ＡｖＧｒＢＷが０より大きいが、要求されたビットレートをサポートするには十分ではない場合には、メッセージ２０８ｂでサービス拒絶が送信される。また、ＭＴＣデバイス２００ｂによって要求されたビットレートが、単一の既存ＧＢＲベアラではなく、複数のＧＢＲベアラの結合によってサポート可能である場合、ＭＭＥ２０２ｂは、サービス要求２０６ｂを拒絶し、さらに新たなベアラ値を通知すること、ベアラ情報を待機すること、ページングを受信するまでサービス要求の再試行をしないことを通知する。こうしたページング情報の待機は、メッセージ２０８ｂによって送信可能である。ＭＭＥ２０２ｂは、ＭＴＣデバイス２００ｂのためのベアラを確立するようＰ－ＧＷ２０３ｂへ要求してもよい。この新しいベアラを実現するため、既存のＧＢＲベアラが破棄され、新たなＧＢＲが作成される必要がある。ある古いＧＢＲベアラが無効化され、ＭＴＣデバイス２００ｂに必要なＧＢＲベアラが作成されると、ＭＭＥ２０２ｂは、ＭＴＣデバイス２００ｂにページングを送信することができる。ＭＴＣデバイス２００ｂはページングを受信し、ＭＭＥ２０２ｂへのサービス要求を実行する。サービス応答において、アップリンクＵプレーントラフィック送信を可能にする新しいＧＢＲベアラの属性がＭＴＣデバイス２００ｂへ送信される。
　ＮＡＳメッセージ２０８ｂがサービス拒絶メッセージである場合、ＭＴＣデバイス２００ｂはランダムな時間だけ待機した後、接続モードに移行するためにサービス要求を再試行する。このような再試行のサービス要求は、図２Ｂのシグナリングメッセージ２０９ｂとして示されている。また、ここでも、グループ内のどのデバイスもアップリンクＵプレーントラフィックの送信を中止せず、ＭＭＥ２０２ｂにおけるＡｖＧｒＢＷの状態に変更はないとする。この再試行サービス要求の間に状態変更がなかったことは、状態２１０ｂとして示されている。この場合、ＭＭＥ２０２ｂは、別のサービス要求拒絶メッセージ２１１ｂをＭＴＣデバイス２００ｂへ送信する。
　このシナリオにおいて、ＭＴＣデバイス２０１ｂがＵプレーントラフィック送信を停止し、その結果、送信中止メッセージ２１２ｂをＭＭＥ２０２ｂへ送信したとする。なお、このメッセージ２１２ｂはオプションのメッセージであり、必ずしも送信される必要はない。ＭＴＣデバイス２０１ｂは、ネットワークからのデタッチを実行する場合に、デタッチＮＡＳメッセージ２１２ｂをＭＭＥ２０２ｂへ送信することが可能である。このデタッチメッセージ２１２ｂは、デタッチ通知のためにさらにＰ－ＧＷ２０３ｂへ送信される。Ｐ－ＧＷ２０３ｂは、デタッチメッセージ２１３ｂを受信すると、ＡｖＧｒＢＷを再計算する。新たなＡｖＧｒＢＷは、シグナリングメッセージ２１４ｂを使用してＭＭＥ２０２ｂへ通知される。なお、シグナリングメッセージ２１４ｂによって通知されるＡｖＧｒＢＷは、ＭＴＣデバイス２００ｂのアップリンクＵプレーントラフィックを送信するのに十分であるとする。
　サービス要求を再試行するメッセージ２１５ｂを再度受信したＭＭＥ２０２ｂは、空いているグループ帯域幅が利用可能な状態（状態２１６ｂ）となっているので、サービス要求受け入れメッセージ２１７ｂをＭＴＣデバイス２００ｂへ送信する。サービス要求が受け入れられたこと（メッセージ２１７ｂ）を考慮し、ＭＴＣデバイス２００ｂは、ＭＴＣサーバ２０４へのＵプレーントラフィックの送信に成功する。このＵプレーントラフィックがメッセージ２１８ｂによって示されている。この方法の利点は、必ずしもベアラ情報を送信する必要がないという点、ＭＴＣデバイスがデータを送信しようとしており、サービス要求を送信する場合にのみ通知が行われるという点にある。これにより、コアネットワークの不要なシグナリング、ページングのシグナリングが送信されるという問題が解決され、また、ＭＴＣデバイスの電力が節約される。しかしながら、図２Ｂに図示されている方法は、送信すべき高優先度トラフィックを有するＭＴＣデバイス２００ｂが、依然として、必要な帯域幅を取得するためにある程度の時間だけ待機しなければならず、また、ＭＴＣデバイス２００ｂが複数回のサービス要求シグナリングを実行して、接続モードに移行しなければならないという課題も有している。
　ＭＴＣデバイス２００ｂがデタッチモードからアタッチモードへ変わる場合には、ＭＴＣデバイス２００ｂは、通常のベアラ作成処理を利用して、ベアラ関連情報を受信する。アタッチモードでは、ＭＴＣデバイス２００ｂがＭＭＥ２０２ｂへ問い合わせを行って関連するベアラパラメータを取得するか、又は、ＭＭＥ２０２ｂがベアラ情報を格納せずに渡すことが可能である。なお、３ＧＰＰ構成に関連して説明を行ったが、当業者であれば、同様の動作を行う他の構成に上述の方法を適用することが可能である。
＜本発明の主要な動作＞
　次に、本発明の好適な実施の形態における動作について説明する。本発明の主要な基本原理は上述した通りであるが、ここでは、任意のネットワークアーキテクチャにおける動作について説明する。この任意のネットワークアーキテクチャは、主に３つの構成要素（例えば、ＭＴＣデバイス、ＭＴＣサーバ、ＭＴＣデバイスがＭＴＣサーバへ到達するためのネットワークコンポーネント）から構成される一般的なアーキテクチャである。このネットワークコンポーネントは、ＭＴＣデバイスからのユーザプレーントラフィック及び制御プレーントラフィックの伝送を可能にするルータ及びゲートウェイによって構成されると考えることができる。また、このネットワークコンポーネントは、アクセスネットワーク、伝送ネットワーク、さらには一般的なインターネットをも構成すると考えることができる。さらに、このネットワークコンポーネントは、接続されている各ＭＴＣデバイスに関して、単一又は複数のベアラを作成、維持することが可能である。上述のように、ＭＴＣデバイスがＵプレーン伝送のためにベアラを使用する場合、ベアラは、Ｕプレーントラフィックに提供されるＱｏＳサポートのレベルという特徴を有している。なお、本発明の主要な動作は、特に、本発明の実施の形態におけるＭ２Ｍ通信に関連した通信環境において説明されるが、当業者であれば、本発明は、このＭＴＣデバイスが任意のモバイルデバイスであって、このＭＴＣサーバが任意のタイプのサーバであるような一般的な設定においても適用可能であることが分かるであろう。
　さらに本発明の動作を理解するため、図３Ａに図示されているシグナリング交換について説明する。このようなシグナリング交換の詳細を説明する前に、まず、図３Ａを参照しながら、本発明の高次の動作について説明する。図３Ａにおいて、ＭＴＣデバイス３００ａが、ネットワーク３０１ａを通じてＭＴＣサーバ３０２ａと通信しているとする。ネットワーク３０１ａは、ＭＴＣデバイス３００ａとＭＴＣサーバ３０２ａとの間のパスにおける任意のネットワークエンティティである。図３Ａに図示されている本発明に係る動作は、ＭＴＣデバイス３００ａが、高優先度、広帯域幅、リアルタイムＵプレーントラフィックを送信する必要性をネットワーク３０１ａ（これは、ネットワークエンティティを意味している）へ送信し、ＡｖＧｒＢＷが無い場合にはネットワーク３０１ａは、たとえＭＴＣデバイス３００ａが、接続されている複数のベアラを既に有していたとしても、最小限の帯域幅のベアラをＭＴＣデバイス３００ａが使用することのみを許可する。ＭＴＣデバイスのグループのための利用可能な帯域幅が無い場合（例えば、ＡｖＧｒＢＷ＝０）には、ネットワーク３０１ａは、そのグループのＭＴＣデバイス３００ａに対して、高いＱｏＳを有するベアラの使用の許可を与えることを望まず、その結果、ＭＴＣデバイス３００ａに対して最小限の帯域幅ベアラの割り当てのみを行う。最小限の帯域幅ベアラは、そのベアラに最小限の帯域幅及び低ＱｏＳが関連付けられていることを意味する。最小限の帯域幅ベアラに低ＱｏＳを与えることは、Ｕプレーントラフィックがこのベアラを通じて送信される場合にネットワーク３０１ａが優先的な取り扱いを行う必要がなく、その結果、最低限の帯域幅ベアラを経由して送信されるＵプレーントラフィックが、他のデバイスのＵプレーントラフィックフローに影響を与えないようにすることを意味する。なお、他のデバイスは、そのグループのデバイスではなくてもよい。また、最小限の帯域幅を最小限の帯域幅ベアラに割り当てることによって、ネットワーク３０１ａは、そのグループに属さない他のデバイスからの重要なリソースが、最小限の帯域幅ベアラ経由で送信されるＵプレーントラフィックに使用される必要がないようにすることを意味する。
　ネットワーク３０１ａがこのような最小限の帯域幅のベアラを決定すると、ネットワーク３０１ａは、この最小限の帯域幅のベアラのベアラ識別子を、ＭＴＣデバイス３００ａへ通知する。ＭＴＣデバイス３００ａは、ネットワーク３０１ａによって返信されるベアラが最小限の帯域幅のベアラであると判断すると、静的構成に基づいてそれに関連付けられているＱＣＩを把握し、Ｕプレーントラフィック送信に関連するベアラを使用する際に、内部でＱｏＳパラメータ（すなわち、帯域幅、リンクバッファの特性）の調整を行う。なお、各ＱＣＩスカラは、任意のＱｏＳパラメータにマッピングされていると考えられる。ＭＴＣデバイス３００ａが、最小限の帯域幅ベアラのためのＱＣＩ値や、静的に格納された関連ＱｏＳパラメータを持っていないような場合には、ネットワーク３０１ａは、最小限の帯域幅のベアラのベアラＩＤに加えて、最小限の帯域幅のベアラのためのＱＣＩスカラ値や、このＱＣＩスカラに対応するＱｏＳパラメータを、ＭＴＣデバイス３００ａへ明示的に与えてもよい。
　ＭＴＣデバイス３００ａは、この最小限の帯域幅のベアラについて通知されると、そのベアラを、高優先度、広帯域、リアルタイムＵプレーントラフィックを転送することが可能な何らかの帯域幅を得るための警告メッセージをＭＴＣサーバ３０２ａへ送信するために使用可能なベアラと正しく判断する。最小限の帯域幅のベアラの特性を判断した後、ＭＴＣデバイス３００ａは、この最小限の帯域幅のベアラを使用するためにＱｏＳパラメータを内部で調整する。ＭＴＣデバイス３００ａは、Ｕプレーントラフィック送信レートを、最小限の帯域幅のベアラのＱＣＩに関連する最小限の値に調整し、最小限の帯域幅のベアラに対応するＱＣＩを内部のアップリンクバッファへ入力する。ＭＴＣデバイス３００ａは、ネットワーク３０１ａにおいて帯域幅が不足している状態にあることをＭＴＣサーバ３０２ａへ通知するために、この最小限の帯域幅のベアラを使用する。このとき、ＡｖＧｒＢＷが０以上であるが、ＭＴＣデバイス３００ａに必要なＵプレーントラフィックレートがＡｖＧｒＢＷより大きい場合であっても、ネットワーク３０１ａが、最小限の帯域幅のベアラをＭＴＣデバイス３００ａへ割り当てることが重要である。
　ＭＴＣサーバ３０２ａへ警告が送信されて使用されていた帯域が解放され、ＡｖＧｒＢＷを上回る帯域が存在する状態になると、ＭＴＣサーバ３０２ａは、帯域幅が解放された状態がＭＴＣデバイス３００ａへ通知される。帯域幅が利用可能な状態がＭＴＣデバイス３００ａによって認識されると、ＭＴＣデバイス３００ａは、最小限の帯域幅のベアラのためのＱＣＩを復元するようネットワーク３０１ａへ要求し、それを利用して高優先度、広帯域幅、リアルタイムＵプレーントラフィックをＭＴＣサーバ３０２aへ送信する。
　以下、本発明の詳細な動作について説明する。ＭＴＣデバイス３００ａが、サービス要求シグナリング３０３ａを送信し、高優先度、広帯域幅、リアルタイムトラフィックを送信する予定であることを通知する。ＭＴＣデバイス３００ａが高優先度、広帯域幅、リアルタイムトラフィックを送ろうとしていることを示すトリガは任意の形式が可能であり、例えば、このような必要性を特徴付けるＵプレーントラフィックのビットレート、帯域幅、又は、何らかの識別子であってもよい。ネットワークエンティティ３０１ａは、そのグループに関するＡｖＧｒＢＷをチェックする。そのグループに関するＡｖＧｒＢＷが０の場合、ネットワークエンティティ３０１ａは、最小限の帯域幅のベアラのみが使用可能であることをＭＴＣデバイス３００ａへ通知する。このような最小限の帯域幅のベアラに関する情報は、応答メッセージ３０４ａで提供される。ＭＴＣデバイス３００ａは、応答メッセージ３０４ａを受信すると、最小限の帯域幅のベアラをセットアップするために必要な動作を実行する。なお、最小限の帯域幅のベアラのセットアップは、明示的なシグナリングの有無によらず実行可能である。なお、応答メッセージ３０４ａは、最小限のデータしか送ることができない時間間隔（バックオフタイマ）を示す値を含むサービス要求応答メッセージ（Service Accept）であってもよい。ＭＴＣデバイス３００ａは、受信した応答メッセージ３０４ａの中にバックオフタイマが含まれた場合には、受信したタイマが経過するまでは、高優先度や広帯域なトラフィックを送信することができないと判断する。つまり、バックオフタイマは、ＭＴＣデバイス３００ａが送信したサービス要求に対応するベアラの確立が一定時間（バックオフタイマ経過）後に行われることを示している。この場合、バックオフタイマを通知するネットワーク３０１ａ内のエンティティはＭＭＥである。
　ＭＴＣデバイス３００ａは、このような最小限の帯域幅のベアラの存在及び構成を把握した後、最小限の帯域幅のベアラを使用して、メッセージ３０５ａに示されているようにＭＴＣサーバ３０２ａへ警告メッセージを送信する。また、上述したように、ネットワーク３０１ａから受信した応答メッセージ３０４ａの中にバックオフタイマが含まれていた場合には、ネットワーク３０１ａから受信したバックオフタイマが有効である間は、最小限の帯域幅のベアラを使用して、メッセージ３０５ａに示されているようにＭＴＣサーバ２０２ａへ警告メッセージを送信する。この警告メッセージ３０５ａは、ユーザプレーンメッセージであると考えられ、具体的には、何らかの帯域幅を要求するために送信されるものである。ＭＴＣサーバ３０２ａは、ネットワーク３０１ａと通信を行って、そのグループに関する帯域幅を取得するか、あるいは、何らかの手段を利用して、ＭＴＣデバイス３００ａのために帯域幅を解放する。なお、上記何らかの手段は、他のＭＴＣデバイスがあまり重要なＵプレーントラフィックをＭＴＣサーバ３０２ａへ送信していない場合に、その送信を停止するよう通知することであってもよい。ＭＴＣサーバ３０２ａとネットワーク３０１ａとの間のやり取りは図３Ａには明示されていない。ＭＴＣサーバ３０２ａは、ＭＴＣデバイス３００ａに必要な帯域幅が利用可能であることを確認した後、送信可（Clear-to-Send：ＣＴＳ）アプリケーションレイヤメッセージ３０６ａをＭＴＣデバイス３００ａへ送信する。このアプリケーションレイヤメッセージ３０６ａを受信すると、ＭＴＣデバイス３００ａは、ネットワークエンティティ３０１ａに対してベアラ変更シグナリング３０７ａを実行する。メッセージ３０７ａの目的は、最小限の帯域幅のベアラに対してより高いＱｏＳ特性を回復するよう要求するものであり、その結果、ＭＴＣデバイス３００ａは、高優先度、広帯域幅、リアルタイムＵプレーントラフィックをＭＴＣサーバ３０２ａへ送信することが可能となる。また、ＭＴＣデバイス３００ａに割り当てられるこの最小限の帯域幅のベアラ以外の別の所定のベアラが、ＭＴＣサーバ３０２ａへのＵプレーントラフィックを伝送するために十分であることをＭＴＣデバイス３００ａが把握している場合には、ＭＴＣデバイス３００ａは、最小限の帯域幅のベアラではないこのようなベアラに関してベアラ変更を実行することが可能である。
　ネットワークエンティティ３０１ａは、メッセージ３０７ａによるベアラ変更要求を受け入れる前に、現在のＡｖＧｒＢＷが十分かどうかのチェックを行う。ネットワークエンティティ３０１ａが、メッセージ３０７ａに埋め込まれている要件を満たす十分な帯域幅が存在していることを把握すると、メッセージ３０８ａに示されているように、アクノレッジメントを送信する。アクノレッジメントメッセージ３０８ａでは、ネットワークエンティティ３０１ａは、最小限の帯域幅のべアラの識別子を割り当てるか、あるいは、ＭＴＣデバイス３００ａの高優先度、広帯域、リアルタイムＵプレーントラフィックを伝送することが可能な別の既存のベアラの識別子を割り当てる。メッセージ３０８ａを受信した場合は、ＭＴＣデバイス３００ａは、メッセージ３０８ａにベアラＩＤを付加したＵプレーンメッセージをＭＴＣサーバ３０２ａへ送信する。ＭＴＣサーバ３０２ａへのＵプレーンデータメッセージは、メッセージ３０９ａによって図示されている。
　本発明の動作に係る上述の説明から、ＡｖＧｒＢＷが０、又は、ＭＴＣデバイス３００ａが高優先度ＵプレーントラフィックをＭＴＣサーバ３０２ａへ送信できない程度の低い値の場合に、本発明の方法を適用することで、従来技術に係る非効率性を伴わずに、必要な帯域幅が取得できることは明らかである。本発明の方法を利用して、ＭＴＣサーバ３０２ａと通信を行うために、低減されたＱｏＳを有する最小限の帯域幅のベアラがセットアップされ、その結果、ＭＴＣサーバ３０２ａは、低優先度トラフィックを送信するその他のＭＴＣデバイスを外して、ＡｖＧｒＢＷの状態をより高い値に戻すことが可能となる。この最小限の帯域幅のベアラの特別な性質は、最小限の帯域幅のベアラが既存のベアラのＱｏＳが変更されたものである場合には、変更されたＱｏＳをＭＴＣデバイス３００ａ又はルータへ通知するためにネットワークにおいて明示的なベアラ変更シグナリングの付加が行われることなく、最小限の帯域幅のベアラがＭＴＣデバイス３００ａへ割り当てられることである。最小限の帯域幅のベアラを使用してＵプレーントラフィックをＭＴＣサーバ３０２ａへ送信する際には、最小限の帯域幅のベアラのＩＤが付加され、パス上のルータは、このＩＤが最小限の帯域幅のベアラに関連していることを把握し、Ｕプレーントラフィックに関して必要最小限のＱｏＳ処理を行う。なお、最小限の帯域幅のベアラのＩＤは固有であり、最小限の帯域幅ベアラのみに関連しているとする。その結果、Ｕプレーントラフィックのパス上のルータは、たとえ明示的なベアラ変更シグナリングをネットワークから受信しなかったとしても、最小限の帯域幅のベアラのＩＤを確認したときは、行うべきＱｏＳ処理を把握する。また、既存のベアラが最小減の帯域幅のベアラである場合に、そのベアラのＩＤが最小限の帯域幅のベアラのＩＤに変更される。このような最小限の帯域幅のベアラの判断では、最小限の帯域幅のベアラのＩＤが特定のＱｏＳへマッピングされており、このようなマッピングがルータ及びＭＴＣデバイス３００ａにも事前に格納されていると考えられる。
＜３ＧＰＰシナリオにおける本発明の詳細な動作－最小限の帯域幅のベアラが変更されたＱＣＩを有するデフォルトベアラである場合＞
　上述では、図３Ａに示されるシグナリング交換を実行する動作を参照しながら、以下では、デフォルトベアラが使用される場合について説明する。以下、最小限の帯域幅ベアラとしてデフォルトベアラが使用される場合について説明する。ＭＴＣデバイスとＭＴＣサーバとの間のネットワークが、非特許文献２に開示されているネットワークアーキテクチャを有し得る３ＧＰＰネットワークセグメントの場合における本発明の詳細な動作について説明する。最小限の帯域幅のベアラとして使用されるデフォルトベアラに関して、２つの場合が存在する。第１の場合は、ＭＴＣデバイスがデフォルトベアラのみを有しており、ＱｏＳが低減されたデフォルトベアラが最小限の帯域幅のベアラとみなされる場合である。第２の場合は、ＭＴＣデバイスがデフォルトベアラ及び専用ベアラを有しており、デフォルトベアラのＱｏＳを低減させずに、デフォルトベアラのみが最小限の帯域幅のベアラとして割り当てられる場合である。第２の場合において、デフォルトベアラが最小限の帯域幅のベアラとして使用されるとき、デフォルトベアラに関連するＱｏＳが低く、かつ、デフォルトベアラのためのＱｏＳパラメータを低減させる必要がないと仮定する。したがって、第２の場合には、第１の場合のようにＱＣＩ値を変更させる必要はない。
　さらに、図３Ｂを参照しながら、３ＧＰＰの設定において、デフォルトベアラが最小限の帯域幅ベアラとして使用される場合の詳細な動作について説明する。ここでは、まず、ＭＴＣデバイスに関連して単一のデフォルトベアラのみが存在する場合について説明し、続いて、ＭＴＣデバイスに割り当てられている専用ベアラが存在する場合について説明する。
　図３Ｂでは、ＭＴＣデバイス３００ｂ、３０１ｂは、通常、ＭＴＣサーバ３０４ｂと通信を行うものであり、Ｇ－ＡＭＢＲが課されているとする。また、ＭＴＣデバイス３００ｂ、３０１ｂには、例えば、Ｐ－ＧＷなどのネットワークエンティティ３０３ｂからＩＰアドレスが割り当てられるとする。以降、ネットワークエンティティ３０３ｂはＰ－ＧＷであるとする。また、ＭＴＣデバイス３００ｂ、３０１ｂはＭＭＥ３０２ｂに接続されているとする。このような３ＧＰＰ指向の設定では、ＭＴＣデバイス３０１ｂは、ＭＴＣサーバ３０４ｂとＵプレーン通信セッションを有しているとする。さらに、ＭＴＣデバイス３００ｂは、ＭＴＣサーバ３０４ｂへ送信すべき高優先度、広帯域幅、リアルタイムＵプレーントラフィックを有しており、ＭＴＣデバイス３００ｂは現在アイドルモードであるとする。
　さらに、ＭＴＣデバイス３００ｂは、デフォルトベアラのみがセットアップされており、このようなデフォルトベアラの状態は、例えばＭＭＥ３０２ｂ、Ｐ－ＧＷ３０３ｂ、さらにはＭＴＣデバイス３００ｂなどのネットワークエンティティに保持されているとする。なお、デフォルトベアラの状態は、ベアラＩＤ、ＡＰＮ、ＱＣＩ、ＩＰプレフィックス値などを指すものである。ＭＴＣデバイス３００ｂが、そのフローに関してあまり高いＱｏＳ処理を必要としておらず、デフォルトベアラのみを使用してＭＴＣサーバ３０４ｂと通信を行うことができる場合には、ＭＴＣデバイス３００ｂがデフォルトベアラしか持っていないというシナリオが十分に考えられる。この高優先度ＵプレーントラフィックをＭＴＣサーバ３０４ｂへ送信するために、ＭＴＣデバイス３００ｂは、メッセージ３０５ｂに示されるようにサービス要求メッセージを送信する。ＭＴＣデバイス３００ｂは、高優先度、広帯域幅、リアルタイムのＵプレーントラフィックを送信する必要があることを示すためのフラグを、このサービス要求メッセージ３０５ｂに埋め込むことができる。なお、このフラグは、サービス要求メッセージ３０５ｂに付加される新たな情報要素であってもよい。また、ＭＴＣデバイス３００ｂは、このメッセージ３０５ｂに、明示的なビットレート及び帯域幅のプロファイルを埋め込むことも可能である。また、別の派生例として、ＭＴＣデバイス３００ｂが、メッセージ３０５ｂのフラグを送信し、そのフラグを確認したＭＭＥ３０２ｂが、ＭＴＣデバイス３００ｂに関するトラフィックのプロファイルを、格納されたキャッシュやデータベースから取得することが可能である。なお、この例では、ＭＴＣデバイス３００ｂのトラフィックのプロファイルがＭＭＥ３０２ｂにおいて静的に構成されている。メッセージ３０５ｂの受信後、状態３０６ｂに示すようにＡｖＧｒＢＷが０であることをＭＭＥ３０２ｂが把握した場合、ＭＭＥ３０２ｂは、メッセージ３０７ｂに示すようにサービス要求応答メッセージをＭＴＣデバイス３００ｂへ送信することが可能である。この応答メッセージ３０７ｂは、最小限の帯域幅のベアラのベアラＩＤをＭＴＣデバイス３００ｂへ通知することが望ましい。上述の実施の形態のように、ＭＴＣデバイスがアイドルモードの場合には、ベアラ変更メッセージはＭＴＣデバイスへ送信されず、ＭＭＥ３０２ｂでベアラ情報を維持することが可能である。このような最適化された動作によれば、ＭＭＥ３０２ｂは、ＭＴＣデバイス３００ｂのベアラに関するすべての情報を有しており、直ちに適切なメッセージ３０７ｂで応答することが可能である。このベアラ情報には、ＡｖＧｒＢＷの情報が含まれていてもよい。ＭＴＣデバイス３００ｂはメッセージ３０７ｂを受信し、最小限の帯域幅のベアラのベアラＩＤを確認すると、このベアラＩＤが一時的にデフォルトベアラに割り当てられていることを把握し、さらに、ネットワークがＭＴＣデバイス３００ｂへ最小限の帯域幅のベアラを割り当てるつもりであることを理解する。なお、別の実施例では、応答メッセージ３０７ｂに新たな情報要素（Cause Value）を割り当てることが可能であり、ＭＴＣデバイス３００ｂは、それを最小限の帯域幅のベアラの許可と解釈することも可能である。メッセージ３０７ｂに新たな情報要素が存在する場合には、ＭＴＣデバイス３００ｂは、ＭＴＣデバイス３００ｂに格納されている、事前に構成された最小限の帯域幅のベアラのＩＤを特定することが可能である。ＭＴＣデバイス３００ｂは、事前構成によって、最小限の帯域幅ベアラに関連するベアラＩＤを既に把握しており、応答メッセージ３０７ｂ内の情報をすぐに特定できると考えられる。なお、事前構成がない場合であっても、ＭＴＣデバイス３００ｂは、新たなベアラＩＤが応答メッセージ３０７ｂに存在する場合に、それを最小限の帯域幅のベアラのベアラＩＤと判断してもよい。また、応答メッセージ３０７ｂにバックオフタイマが含まれている場合は、そのタイマが有効である間は、最小限の帯域幅のベアラだけが許可されていると解釈する。つまり、そのタイマの有効期限が切れた場合は、通常通りのベアラを生成することが可能であると判断し、高優先度・広帯域向けのサービス要求を送信する。
　最小限の帯域幅のベアラを使用してＵプレーントラフィックを送るとき、ＭＴＣデバイス３００ｂは、上述のように、最小限の帯域幅のベアラが割り当てられていることを把握し、続いて、内部でＱｏＳを変更する。最小限の帯域幅のベアラはデフォルトベアラであり、ＭＴＣデバイス３００ｂは新しいＱＣＩをデフォルトベアラに関連付ける。このような内部での関連付けは、処理３０８ｂによって示されている。最小限の帯域幅のベアラの変更及び構成が内部で行われた後、ＭＴＣデバイス３００ｂは、最小限の帯域幅ベアラＩＤをユーザプレーンパケットに関連付けることによって、Ｕプレーン警告メッセージ３０９ｂをＭＴＣサーバ３０４ｂへ送信する。なお、当業者であれば、デフォルトベアラのＩＤが静的な最小限の帯域幅のベアラのＩＤへ変更され、その結果、すべてのルータがメッセージ３０９ｂに対して最小限のＱｏＳ処理を実行することが分かるであろう。さらに、ＭＴＣデバイス３００ｂは、ＭＴＣサーバ３０４ｂへその状態を通知するため、非常に低い帯域幅のＵプレーントラフィックをＭＴＣサーバ３０４ｂへ送信する。
　ＭＴＣサーバ３０４ｂは、メッセージ３０９ｂを受信すると、ＭＴＣデバイス３００ｂに必要な帯域幅を取得する方法を決定する。ある方法においては、メッセージ３０９ｂに、ＭＴＣデバイス３００ｂが送信しようとしている高優先度Ｕプレーントラフィックのビットレート情報が含まれていてもよい。このようなビットレート情報を把握することによって、ＭＴＣサーバ３０４ｂは、ＭＴＣデバイス３００ｂを収容するために解放すべき帯域幅の量を容易に把握することが可能である。ＭＴＣサーバ３０４ｂがビットレート監視特性を有する場合には、ＭＴＣサーバ３０４ｂは、ＭＴＣデバイス３００ｂのための帯域幅を取得するために送信を停止する必要があるグループ内の他のすべてのデバイスを特定することが可能である。ＭＴＣサーバ３０４ｂは、他のＭＴＣデバイスのフローがさほど重要ではないことを予測できるのであれば、他のＭＴＣデバイスの送信をストップさせるだけでよいと考えられる。ＭＴＣサーバ３０４ｂがこのようなビットレート監視特性を持っていない場合は、シャットダウンが必要なＭＴＣデバイスを特定する際の援助をしてもらうようＰ－ＧＷ３０３ｂと通信を行うことが可能である。しかしながら、ＭＴＣサーバ３０４ｂが、アプリケーションレイヤを有しており、高優先度トラフィックを送信していないグループ内のＭＴＣデバイスを特定する機能を有しているので、送信の中止が可能なＭＴＣデバイスは、ＭＴＣサーバ３０４ｂによってのみ特定される。
　ＭＴＣサーバ３０４ｂは、ＭＴＣデバイス３０１ｂのＵプレーントラフィックが停止可能であることを特定した場合、メッセージ３１０ｂを使用して送信停止メッセージをＭＴＣデバイス３０１ｂへ送信する。ＭＴＣデバイス３００ｂに帯域幅を確実に提供できるようにし、別のＭＴＣデバイスによって使われないようにするため、ＭＴＣサーバ３０４ｂは、Ｐ－ＧＷ３０３ｂに対して、ＭＴＣデバイス３００ｂにおいて必要な帯域幅を明示的に予約するよう要求してもよい。この動作によれば、予約によって、ＭＴＣデバイス３００ｂに関するＡｖＧｒＢＷの値は高くなり、他のデバイスに関するＡｖＧｒＢＷ値は低くなる。ＭＴＣサーバ３０４ｂは、ＭＴＣデバイス３００ｂのために十分な帯域幅が利用可能であると把握すると、ＣＴＳメッセージをＭＴＣデバイス３００ｂへ送信する。このＣＴＳメッセージは、メッセージ３１１ｂによって示される。メッセージ３１１ｂがＭＴＣデバイス３００ｂによって受信されると、ＭＴＣデバイス３００ｂは、デフォルトベアラに対してベアラ変更を実行するよう決定する。ベアラ変更は、デフォルトベアラのＱｏＳ特性をより高い値に回復するために行われる。その結果、ＭＴＣデバイス３００ｂは、高優先度、広帯域幅、リアルタイムＵプレーントラフィックを送信することができる。ＭＭＥ３０２ｂは、デフォルトベアラ変更要求メッセージ３１２ｂを受信し、それが関係する帯域幅より大きいＡｖＧｒＢＷであるという情報を有している場合（状態３１３ｂ）には、ベアラ変更処理を実行してデフォルトベアラのためのＱＣＩを回復させる。デフォルトベアラＩＤ（最小限の帯域幅のベアラのＩＤとは異なる）は、ベアラ変更要求応答メッセージ３１４ｂによって、ＭＴＣデバイス３００ｂへ返される。
　メッセージ３１４ｂによってデフォルトベアラのＩＤを受けると、ＭＴＣデバイス３００ｂは、ＭＴＣサーバ３０４ｂへのアップリンクトラフィック３１５ｂの送信を開始する。なお、派生例として、ベアラ変更要求メッセージ３１２ｂにおいて、ＭＴＣデバイス３００ｂは新たな専用ベアラを要求して、高優先度トラフィックを伝送することが可能である。さらに別の派生例として、ネットワークは、デフォルトベアラを変更する代わりに、専用ベアラを生成することが可能である。新たに生成された専用ベアラのＩＤはメッセージ３１４ｂによって通知可能である。
　次に、既存のデフォルトベアラが最小限の帯域幅のベアラとして、応答メッセージ３０７ｂによってＭＴＣデバイス３００ｂへ単純に通知される第２の場合について説明する。既存のデフォルトベアラが最小限の帯域幅のベアラとして返されると、ＭＴＣデバイス３００ｂは、複数のベアラをそれに関連付けてもよい。この第２の場合では、応答メッセージ３０７ｂは単にデフォルトベアラのＩＤを伝送する。ＭＴＣデバイス３００ｂは、既存のデフォルトベアラのＩＤがメッセージ３０７ｂによって返されると、デフォルトベアラのみがＭＴＣサーバ３０４ｂへ警告メッセージ３０９ｂを送信するために使用可能であり、変更を行わないデフォルトベアラが最小限の帯域幅のベアラであると判断することが可能である。また、ＭＴＣデバイス３００ｂは、応答メッセージ３０７ｂを確認すると、警告メッセージ３０９ｂが最小限の帯域幅で送信される必要があるという判断も行う。この実施例では、デフォルトベアラのＱｏＳは非常に低く、ＭＴＣデバイス３００ｂによるＱｏＳの更なる内部変更が不要であると考えられる。したがって、ステップ３０８ｂは実行される必要はない。また、この第２の場合においても、応答メッセージ３０７ｂにバックオフタイマが含まれている場合は、そのタイマが有効である間は、デフォルトベアラが最小限の帯域幅のベアラであると判断してもよい。そして、このバックオフタイマが有効である間は、警告メッセージ３０９ｂがデフォルトベアラ上で送信される必要があるという判断も行う。
　デフォルトベアラが最小限の帯域幅のベアラとして単に使用され、複数のベアラがＭＴＣデバイス３００ｂに関連付けられる実施例では、ＭＴＣデバイス３００ｂは、ベアラ変更要求３１２ｂにおいて、デフォルトベアラに関連するＱｏＳよりも高いＱｏＳを持つようデフォルトベアラを変更する要求を行うことが可能であるか、あるいは、既存の専用ベアラに対してベアラ変更を要求することが可能である。なお、ＭＴＣデバイス３００ｂは、メッセージ３１２ｂの代わりに、単純に新たな専用ベアラを要求することも可能である。ＭＭＥ３０２ｂは、要求３１２ｂを処理する方法を判断する。ＭＭＥ３０２ｂが要求３１２ｂを処理することができる方法は複数存在し、どの方法で判断を行ったとしても、本発明の主要なポイントに影響を与えるものではない。
＜本発明の別の動作－最小限の帯域幅のベアラが明示的に生成される＞
　ＡｖＧｒＢＷが存在しない場合に、最小限の帯域幅のベアラが明示的に生成されることが望ましい構成も存在する。以下、このような実施例について説明する。デフォルトベアラのＱｏＳ特性が非常に低いＱｏＳ値への変更を禁止されている場合には、図３Ｃに図示されているように、最小限の帯域幅の専用ベアラを生成し、その最小限の帯域幅の専用ベアラのＱｏＳ特性を改善することが適切である。このように、最小限の帯域幅の専用ベアラを生成することが有用な場合がある。さらに、デフォルトベアラと共に、最小限の帯域幅の専用ベアラを使用する場合もある。この場合、最小限の帯域幅の専用ベアラが最小限のＱｏＳを必要とするトラフィックのために使用される場合もある。
　以下、図３Ｃを参照しながら、この本発明の別の実施例の主要なステップについて説明する。本発明の主要な動作環境において、ＭＭＥが、ＭＴＣデバイスの１つ又は複数のベアラに関係するＡｖＧｒＢＷに関連したベアラコンテキストを維持し、ＭＴＣデバイスがサービス要求処理を実行するまで、ベアラコンテキストをＭＴＣデバイスへ提供しないようにすることが可能である。このベアラコンテキストは、Ｐ－ＧＷ始動のベアラ変更処理を利用して、Ｐ－ＧＷから提供されると考えられる。以下、このような動作について詳述する。
　ＭＴＣデバイス３００ｃ、３０１ｃは、通常ＭＴＣサーバと通信を行い、グループベースの通信シナリオであるとする。また、ＭＴＣサーバ３０４ｃと通信を行っているＭＴＣデバイスは、Ｇ－ＡＭＢＲが課せられているとする。また、ＭＴＣデバイス３０１ｃが現在アップリンクトラフィックをＭＴＣサーバ３０４ｃへ送信している一方、ＭＴＣデバイス３００ｃはアイドルモードであるとする。なお、ＭＴＣデバイス３００ｃは、関連する複数のベアラを有していてもよい。さらに、ある経過時間後に、ＭＴＣデバイス３００ｃは、ＭＴＣサーバ３０４ｃへ送信すべきＵプレーントラフィックを有するものとする。さらに、ＭＴＣデバイス３００ｃが送信しようとしているＵプレーントラフィックが、高優先度、広帯域、リアルタイムのタイプのトラフィックであるとする。さらに、ＭＴＣデバイス３００ｃが、高優先度及び広帯域トラフィックのようなＵプレーントラフィックを分類することが可能な適切なアプリケーションレイヤインテリジェンスを有しているとする。さらに、ＭＴＣデバイス３００ｃのアプリケーションレイヤが、さらにこうしたトラフィック分類（すなわち、高優先度及び広帯域）をＮＡＳレイヤへ渡し、その結果、ＮＡＳレイヤで開始されるサービス要求が、サービス要求メッセージ内に高優先度トラフィック通知を埋め込むとする。ＭＴＣデバイス３００ｃのＮＡＳレイヤは、こうした高優先度トリガを受信すると、ＭＴＣデバイス３００ｃがサービス要求メッセージ３０５ｃをＭＭＥ３０２ｃへ送信する。このサービス要求メッセージ３０５ｃには、ＭＴＣデバイス３００ｃが、高優先度及び広帯域トラフィック伝送に関するサービス要求を実行していることを示す情報要素が存在する。
　ＭＭＥ３０２ｃは、サービス要求シグナリングメッセージ３０５ｃを受信すると、まず、ＡＶＧｒＢＷがＭＴＣデバイス３００ｃのトラフィックのプロファイルを伝送するのに十分かどうかをチェックする。このようなトラフィックのプロファイル又はトラフィック特性は、サービス要求メッセージ３０５ｃに埋め込まれてもよく、また、このようなトラフィックのプロフィールのパラメータは、ビットレートであってもよい。状態３０６ｃによって示されているように、ＡｖＧｒＢＷが十分ではなく、その結果、シグナリングメッセージ３０５ｃに関する要求をサポートできない場合には、ＭＭＥ３０２ｃは、最小限の帯域幅の専用ベアラ生成処理を始動する。このような最小限の帯域幅のベアラ作成シグナリング処理は、メッセージ３０７ｃによって示されている。最小限の帯域幅の専用ベアラは、デフォルトベアラが通常関連付けられているものよりも小さいＱＣＩ（ＱｏＳ）を有している。通常、デフォルトベアラはＵプレーントラフィックに使用され、相対的に高いＱｏＳ取り扱いを有すると考えられる。しかしながら、最小限の帯域幅の専用ベアラは、主に警告又はヘルプトリガをＭＴＣサーバ３０４ｃへ送信するために使用されるため、最小限の帯域幅の専用ベアラに関しては高いＱｏＳで処理される必要はない。最小限の帯域幅の専用ベアラは、非常に小さい帯域幅が関連付けられている。
　ＭＭＥ３０２ｃが十分な量のＡｖＧｒＢＷを有しており、ＭＴＣデバイスのトラフィックを伝送するために必要な帯域幅がＡｖＧｒＢＷより小さい場合には、ＭＭＥ３０２ｃは、ＭＴＣデバイス３００ｃに関連したトラフィックのために、どのベアラを割り当てるべきか（すなわち、ベアラ識別子）をチェックする。サービス要求３０５ｃがＧＢＲベアラを所望し、ＭＴＣデバイス３００ｃのＧＢＲベアラのための帯域幅がトラフィックの伝送に十分な場合には、ＧＢＲベアラが提供される。また、このようなＧＢＲベアラ要求がメッセージ３０５ｃによって提供されず、非ＧＢＲベアラプールに対して利用可能な帯域幅がトラフィックの伝送に十分な場合には、非ＧＢＲベアラが提供される。また、必要なベアラが、任意の量の帯域幅を有するＧＢＲベアラであるが、必要な帯域幅値を有するＧＢＲベアラがＭＴＣデバイス３００ｃのために存在しない場合には、ＭＭＥ３０２ｃは、既存のＧＢＲベアラを無効化し、ＭＴＣデバイス３００ｃのための広帯域ＧＢＲベアラを１つ生成する。また、要求がどんなベアラであってもよく、非ＧＢＲプールに関連する帯域幅が十分ではない場合には、ＧＢＲベアラが無効化され、非ＧＢＲベアラが提供されてもよい。また、上述の説明から、ＡｖＧｒＢＷがＭＴＣデバイス３００ｃのトラフィックを伝送するために十分ではない場合には、最小限の帯域幅の専用ベアラが生成されることは明らかである。その他の場合においては、適当なベアラが特定され、サービス要求応答メッセージ３０８ｃによって提供される。
　すべての非ＧＢＲベアラが利用可能な帯域幅、及び、所定のＭＴＣデバイスの全ての単一ＧＢＲベアラに関連する帯域幅の総和は、ＡｖＧｒＢＷ値に等しいことが重要である。例えば、４つの非ＧＢＲベアラと２つのＧＢＲベアラとが存在し、各ＧＢＲベアラに関連する帯域幅が１０ユニットであり、ＡｖＧｒＢＷが６０ユニットの場合には、すべての非ＧＢＲベアラが利用可能な帯域幅は、（６０－（１０＋１０））＝４０ユニットとなる。また、非ＧＢＲベアラプールに関連する帯域幅は、ＡｖＧｒＢＷ－（ＧＢＲベアラ全ての関連する帯域幅）となる。
　最小限の帯域幅の専用ベアラは、様々な方法で作成することが可能である。非特許文献２で説明されている既存のベアラ新規作成処理によれば、ＭＭＥ始動のベアラ生成処理は存在しないが、本発明に係る最小限の帯域幅の専用ベアラの作成に関しては、ＭＭＥ３０２ｃが、新しいシグナリング処理を用いることでＰ－ＧＷ３０３ｃに対してベアラ生成要求をトリガできるようにしてもよい。ＭＭＥ３０２ｃは、何らかの特別なトリガをＰ－ＧＷ３０３ｃへ送信することが可能であり、Ｐ－ＧＷ３０３ｃは、Ｐ－ＧＷ始動の専用ベアラ生成処理を開始することができる。この最小限の帯域幅の専用ベアラは、最小限のＱｏＳパラメータを提供する専用ベアラ及び非ＧＢＲベアラである。もし、ＡｖＧｒＢＷが存在せずに（すなわち、ＡｖＧｒＢＷが０）、最小限の帯域幅専用ベアラが生成されると、Ｐ－ＧＷ３０３ｃは、この最小限の帯域幅の専用ベアラに関してトラフィックのシェーピングを実行せず、ＰＣＲＦに対してＧ－ＡＭＢＲ違反を通知する必要がある。
　最小限の帯域幅の専用ベアラが作成されると、サービス要求成功ＮＡＳメッセージ３０８ｃが、ＭＴＣデバイス３００ｃへ送信されることが望ましい。ＭＴＣデバイス３００ｃは、最小限の帯域幅の専用ベアラが確立されたことを示すサービス応答メッセージ３０８ｃを確認すると、最小限の帯域幅の専用ベアラを使用して、本質的には制御トラフィックと同様のアプリケーションのトラフィックを送信する。なお、応答メッセージ３０８ｃにバックオフタイマが含まれている場合は、そのタイマが有効である間は、警告メッセージを送信するための最小限の帯域幅の専用ベアラだけが許可されていると解釈する。つまり、そのタイマの有効期限が切れた場合は、通常通りのベアラを生成することが可能であると判断し、高優先度・広帯域向けのサービス要求を送信する。さらに、この最小限の帯域幅の専用ベアラに関するＥＰＳベアラ識別子は、メッセージ３０８ｃによって送信されるとする。このようなＭＴＣサーバ３０４ｃに送信されるＵプレーン警告メッセージは、メッセージ３０９ｃとして示される。このＵプレーン警告メッセージ３０９ｃを受信すると、ＭＴＣサーバ３０４ｃは、グループ内の高優先度又は重要なトラフィックに関わっていないと考えられる他のＭＴＣデバイスのトラフィックを特定する処理を開始する。ここで、ＭＴＣサーバ３０４ｃは、重要ではないトラフィックを送信しているデバイスとして、ＭＴＣデバイス３０１ｃを特定したとする。また、ＭＴＣサーバ３０４ｃは、重要ではないトラフィックを識別するために十分なインテリジェンスを持っており、その結果、ＭＴＣサーバ３０４ｃが、送信を停止させるためにＭＴＣデバイス３０１ｃへのアプリケーションレイヤメッセージの送信を行うとする。このような送信停止メッセージは、メッセージ３１０ｃとして示される。ＭＴＣサーバ３０４ｃは、ＭＴＣデバイス３０１ｃが送信を中止したことを特定すると、さらに、最小限の帯域幅の専用ベアラを使用してＭＴＣデバイス３００ｃへ送信可（ＣＴＳ）アプリケーションメッセージを送信する。あるＭＴＣデバイス３０１ｃがグループ帯域幅を共有しないように外すことによって、他のＭＴＣデバイス３００ｃのための十分な帯域幅を確保することが可能となる。また、送信停止の依頼が可能な他のＭＴＣデバイスが存在しないか（すなわち、グループ内の他のＭＴＣデバイスも高優先度トラフィックを送信している）、又は、グループに属する任意の他のＭＴＣデバイスをグループから外しても必要な帯域幅を得ることができない場合には、ＭＴＣデバイス３００ｃは、帯域幅が解放されるのを待機する必要がある。しかしながら、一般的に、ＭＴＣデバイス３００ｃが高優先度トラフィックを送信しようとしているときに、グループ内の他のＭＴＣデバイスも高優先度トラフィックを送信している場合は非常に稀であり、その結果、上述の待機時間は許容可能な限界内となることが多いと考えられる。また、ＭＴＣデバイス３０１ｃを外した後に帯域幅が十分であるかどうかを決定する方法や、送信可メッセージ３１１ｃを送信するよう決定する方法においても、多くの様々な実施例が存在する。ある実施例では、ＭＴＣサーバ３０４ｃがビットレート監視機能を有し、この機能を用いてＭＴＣデバイス３００ｃへのＣＴＳの送信を決定することが可能である。
　ＭＴＣデバイス３００ｃは、送信可メッセージ３１１ｃを受信すると、新たなＧＢＲベアラに関して全く新しい要求を生成するのではなく、最小限の帯域幅の専用ベアラのベアラ変更を行うよう要求する付加的な決定処理をトリガする。このようなベアラ変更処理は、ＧＢＲベアラに必要な帯域幅を取得するために実行される。非特許文献２で説明されているベアラ作成及び変更に関連する標準的な処理によれば、専用ベアラの生成はＰ－ＧＷ３０３ｃによってのみ実行可能である。従って、ＭＴＣデバイス３００ｃが、最小限の帯域幅専用ベアラに関してベアラ変更処理を始動することが最も適切である。最小限の帯域幅の専用ベアラを要求するベアラ変更要求は、ＭＭＥ３０２ｃへ送信されるシグナリングメッセージ３１２ｃによって示されている。通常、ベアラ変更要求はＮＡＳメッセージである。ＭＭＥ３０２ｃは、ベアラ変更要求をＭＴＣデバイス３００ｃから受信すると、現在の利用可能なグループ帯域幅の状態３１３ｃに基づいて適切にベアラ変更要求に対して応答を行う。
　ＭＴＣデバイス３０１ｃからの送信停止によって、状態３１３ｃは、適切なＡｖＧｒＢＷを反映して、ＭＴＣデバイス３００ｃの高優先度トラフィックを伝送できるようにするものである。ＭＴＣデバイス３０１ｃが送信を停止すると、Ｐ－ＧＷ３０３ｃが、ＭＭＥ３０２ｃに対してＡｖＧｒＢＷ情報の通知を行うとする。その結果、ＭＭＥ３０２ｃは、ベアラ変更要求３１２ｃに対して肯定的なアクノレッジメントメッセージを送信する。このようなアクノレッジメントメッセージはシグナリングメッセージ３１４ｃによって示される。最小限の帯域幅の専用ベアラに関するベアラ変更は、Ｐ－ＧＷ３０３ｃで実行されてＭＭＥ３０２ｃへ通知されてもよく、あるいは、ＭＭＥ３０２ｃで実行されてＰ－ＧＷ３０３ｃへ通知されてもよい。ＭＴＣデバイス３００ｃは、最小限の帯域幅の専用ベアラに関する適切なベアラ変更をＭＭＥ３０２ｃから受信すると、ＭＴＣサーバ３０４ｃへのＵプレーントラフィックの送信を開始する。このＭＴＣサーバ３０４ｃへのトラフィックはメッセージ３１５ｃによって示される。
　上記解決方法の説明から、ＭＴＣデバイス３００ｃは、再試行シグナリングを追加することなく、高優先度及び広帯域幅トラフィックをＭＴＣサーバ３０４ｃへ送信するために必要な帯域幅を取得し、これにより、本発明の目的を実現することが可能である。必要な帯域幅は、このような最小限の帯域幅の専用ベアラをセットアップすることによって取得される。なお、上述の解決方法の派生例は３ＧＰＰ特有のシナリオで説明されているが、これらの派生例に関してもは、本発明を逸脱しない範囲で、同様の動作方法を有するシステムに適用可能である。
＜本発明の別の動作－ＭＴＣサーバがネットワークエンティティへ管理を委譲する＞
　また、本発明の別の実施例では、ＭＴＣサーバからのＣＴＳメッセージがＭＴＣデバイスへ送信される必要はない。寧ろ、Ｐ－ＧＷは、ＡｖＧｒＢＷへの状態変更を検出すると、ベアラ変更要求をＭＭＥへ送信し、ＭＴＣデバイスに必要な帯域がＭＴＣサーバによって解放されたかどうかをＭＭＥが判断することが可能である。ＭＭＥは、帯域が解放されることを決定すると、Ｐ－ＧＷから送信されたベアラ変更メッセージをＭＴＣデバイスへ渡す。以下、この本発明の好適な実施の形態の派生例について説明する。なお、本発明に係るこの派生例の動作を３ＧＰＰ特有の構成を用いて説明するが、当業者であれば、ＭＴＣデバイスとＭＴＣサーバとの間のパスが任意の一般的なネットワークセグメントであっても、同様の動作が有効であることが分かるであろう。
　図４において、ＭＴＣデバイス４００は、通常、ＭＴＣサーバ４０４に対してＰ－ＧＷ４０３経由でＵプレーントラフィックを送信する。ＭＴＣデバイス４０１がＵプレーントラフィックをＭＴＣサーバ４０４へ送信しており、ＭＴＣデバイス４００がアイドルモードであるとする。また、ＭＴＣデバイス４００、４０１は、グループベースの通信をＭＴＣサーバ４０４との間で行い、グループ帯域幅の上限が課せられているとする。また、本発明の説明における動作の全ての仮定が適用され、動作の詳細及び仮定は上述の通りであるため、ここでは説明を省略する。
　上述の本発明の動作と同様に、ＭＴＣデバイス４００は、メッセージ４０６に示されているように、高優先度トラフィック伝送トリガが付加されたサービス要求メッセージを送信することが可能である。次に、ＭＭＥ４０２は、状態４０７を使用し、ＭＴＣデバイス４００のトラフィック要件を満たす利用可能なグループ帯域幅が利用可能ではないことを決定する。ＭＭＥ４０２は、最小限の帯域幅のベアラを決定し、望ましくはサービス要求応答メッセージ４０８によって、最小限の帯域幅のベアラのベアラ識別子を通知する。次に、ＭＴＣデバイス４００は緊急のトラフィックの警告をＭＴＣサーバ４０４へ送信する。このメッセージ（ＰＡＭ：Priority Alarm Message）はメッセージ４０９によって示される。そして、ＭＴＣサーバ４０４は、ＭＴＣデバイス４００がグループ帯域幅の共有から除外可能かどうかをチェックする。ＭＴＣサーバ４０４は、ＭＴＣデバイス４００に関連するビットレートを取得するためにＰ－ＧＷ４０３と通信を行って、どのデバイスがグループ帯域幅の共有から除外する必要があるかをチェックする。なお、ＭＴＣサーバ４０４とＰ－ＧＷ４０３との間のやり取りは、インタフェース４１２を使用して行うことが可能である。ＭＴＣサーバ４０４がＰ－ＧＷ４０３と通信を行うため、Ｐ－ＧＷ４０３とＭＴＣサーバ４０４との間にアプリケーションプロトコルインタフェース（Application Protocol Interface：ＡＰＩ）が必要となる。通信が中止される必要があるＭＴＣデバイスを特定することをＭＴＣサーバ４０４が決定する際のチェック処理は、状態４１０によって示される。ＭＴＣサーバ４０４は、このようなＭＴＣデバイス４００を特定すると、送信停止メッセージ４１１をＭＴＣデバイス４０１へ送信する。
　ここで図３Ａとは異なり、ＭＴＣサーバ４０４は、ＣＴＳメッセージをＭＴＣデバイス４００へ送信しない。ＭＭＥ４０２は、ＭＴＣデバイス４００に対して高優先度及び広帯域幅トラフィックの送信を開始するための通知処理を援助する。ＭＴＣデバイス４０１が送信を中止すると、Ｐ－ＧＷ４０３におけるＡｖＧｒＢＷの状態が変更され、ＡｎＧｒＢＷの値がＰ－ＧＷ４０３において増大する。その結果、Ｐ－ＧＷ４０３は、上述のようにベアラ変更処理を利用して、ベアラ変更シグナリング４１３をＭＴＣデバイス４００へ送信する。ＭＭＥ４０２は、これらのベアラ変更シグナリング４１３を調べ、ＡｖＧｒＢＷがＭＴＣデバイス４００に高優先度及び広帯域トラフィックを転送させるのに十分かどうかを決定する。このような決定処理は、上述のものと同様であり、ここでは説明を省略する。
　ＭＭＥ４０２は、ＭＴＣデバイス４００がサービスを開始することができると判断すると、ＭＴＣデバイス４００が使用すると思われるベアラに関して、関連ベアラ変更メッセージをＭＴＣデバイス４００へ渡す。あるいは、最小限の帯域幅専用ベアラが存在するだけならば、ＭＭＥ４０２は、この最小限の帯域幅の専用ベアラに関連するベアラ変更メッセージをＭＴＣデバイス４００へ渡す。ＭＭＥ４０２からＭＴＣデバイス４００へ送信されたベアラ変更シグナリングメッセージは、シグナリング４１４によって示されている。ベアラ変更メッセージ４１４を受信すると、ＭＴＣデバイス４００は、そのアップリンク高優先度トラフィック伝送に対して、通知された専用ベアラを使用することが可能である。また、専用ベアラが存在しない場合には、ＭＭＥ４０２は、デフォルトベアラのみをＭＴＣデバイス４００へ通知する。このようなＵプレーントラフィック伝送は、メッセージ４１５によって示される。
　この方法の主な利点は、図４に説明されているように、ＭＴＣデバイス４００がベアラ変更処理を始動する必要がないことである。その結果、電力制約のあるＭＴＣデバイスのバッテリ電力を節約できるという利点がある。また、別の利点として、ＭＴＣデバイス４００がＣＴＳメッセージを待機する必要がなく、必要なベアラを取得するまでの待ち時間が小さいという利点もある。明示的な最小限の帯域幅のベアラが生成される本発明の別の動作として、最小限の帯域幅の専用ベアラが、初期アタッチ処理の間に生成されてネットワークによって維持されるようにすることも可能である。最小限の帯域幅の専用ベアラは非常に小さいネットワークリソースしか使用しないので、このベアラは、ネットワークに負荷をかけることなく、事前に生成可能でありネットワークで維持可能であると考えられる。また、最小限の帯域幅の専用ベアラを事前に作成する利点として、最小限の帯域幅のベアラが作成されるのを待つことなく、メッセージ４０８のようなサービス要求応答メッセージが送信可能となる点も挙げられる。
＜ＭＴＣデバイスの機能図＞
　次に、本発明の好適な実施の形態におけるモバイルデバイス（例えば、ＭＴＣデバイス）の機能アーキテクチャについて説明する。以下、図５を参照しながら、各機能コンポーネントについて説明する。図５に示される機能コンポーネントは、本発明を実行するモバイルデバイスの好適な実現手段である。しかしながら、当業者であれば、図５に図示されている主要な機能コンポーネントは、本発明の範囲から逸脱しない別の方法で実現可能であることが分かるであろう。
　図５に図示されている機能アーキテクチャは、上述されている本発明を実行するためにＭＴＣデバイスで必要となるすべてのハードウェア、ソフトウェア、フォームウェアを有している。ＭＴＣデバイスの機能アーキテクチャ５００は、例えば、アプリケーションレイヤ５０５、ＩＰレイヤ（ＩＰルーティングレイヤ）５０４、ＮＡＳレイヤ５０３、ＡＳレイヤ５０２、無線通信レイヤ５０１などの機能ブロックを有している。このような標準的なレイヤ又は機能ブロックに加えて、機能アーキテクチャ５００は、さらに、本発明に係る動作を実現するためのモジュール（最小限ベアラ必要性推定モジュール５０６、高品質（高優先度＋広帯域幅）サービス要求トリガモジュール５０７、最小限広帯域幅ベアラ変更決定モジュール５０８、最小限広帯域幅ベアラ変更トリガモジュール５０９）を有している。さらに、これらの機能エンティティ間には、モジュール間で情報の受け渡しを行うための適切なシグナリングインタフェースが設けられている。
　ＮＡＳレイヤ５０３は、主に、ＭＴＣデバイスとそのＭＭＥとの間のＮＡＳシグナリングのやり取りに使用される。このようなＮＡＳシグナリングは、トラッキングエリア更新、アイドル状態からアクティブ状態への変更時のサービス要求、ＰＤＮコネクション確立、ＰＤＮコネクション削除、ベアラ変更処理、アタッチ処理、デタッチ処理において使用可能である。また、ＡＳレイヤ５０２は、ＭＴＣデバイスとｅＮＢ間の全てのシグナリングのために使用される。ＡＳレイヤ５０２のシグナリングは、ＭＴＣデバイスとｅＮＢとの間の無線ベアラを確立するために使用される。また、ＡＳレイヤ５０２は、セル選択とセル監視機能のために用いられる。アプリケーションレイヤ５０５からのユーザプレーントラフィックは、ＩＰレイヤ５０４を経由して送信されてＡＳレイヤ５０２に届き、最終的に無線通信レイヤ５０１経由で送信される。ユーザプレーンパケットのデータユニット伝送を実現するため、インタフェース５１２、５１１、５１０が使用される。同様に、ＮＡＳメッセージを伝送するために、適切なインタフェースがＮＡＳレイヤ５０３において使用される。このようなインタフェースは、図５で示されるインタフェース５１４、５１０である。また、無線通信レイヤ５０１は、ＭＴＣデバイスの物理レイヤのプロトコルを有している。
　ＭＴＣデバイスは、送信すべき高優先度及び広帯域幅トラフィックを有していると判断すると、高優先度及び広帯域幅トリガが埋め込まれたサービス要求をトリガする。高優先度トラフィックのためのサービス要求をトリガするという判断は、モジュール５０６で実行される。高優先度トラフィックのためのサービス要求をトリガするという判断は、ＮＡＳレイヤ５０３からのトリガに基づいて、又は、アプリーケーションレイヤ５０５へのダイレクトインタフェースを使用することによって行われ得る。例えば、アプリケーションレイヤ５０５は、ＭＴＣデバイスが高優先度トラフィックを有しているをモジュール５０６へ通知すると、広帯域幅ベアラが必要とされ、高優先度トリガがサービス要求に含まれる必要があると判断することができる。このような決定がモジュール５０６で行われると、制御はインタフェース５１５を通じてモジュール５０７へ渡される。
　モジュール５０７は、ＮＡＳレイヤ５０３へ渡されるべき関連データを形成又は収集する。この関連データは、ビットレートや、高優先度、広帯域幅トラフィックなどを表すための何らかのデータであってもよい。モジュール５０７は、インタフェース５１６を使用してＮＡＳレイヤ５０３へ制御データを渡す。また、モジュール５０７は、最小限の帯域幅のベアラに関するネットワークからの応答情報を処理する機能を有している。最小限の帯域幅のベアラがデフォルトベアラであり、最小限の帯域幅のベアラのＩＤが固有である場合には、ＭＴＣデバイスは、この情報を処理し、ＱｏＳを内部で変更する。このような機能もモジュール５０７に関連付けられている。
　ＮＡＳレイヤ５０３は、新たな情報要素に高優先度トラフィックであることが挿入されたサービス要求メッセージを生成し、ＡＳレイヤ５０２及び無線通信レイヤ５０１を通じて高優先度トラフィックのためのサービス要求を送信する。このサービス要求を送信した後、ＭＴＣデバイスはＭＴＣサーバからＣＴＳを受信する。このような場合に、アプリケーションレイヤ５０５は、モジュール５０８へトリガを送信し、最小限の帯域幅のベアラのためのベアラ変更処理をトリガできることを通知する。アプリケーションレイヤからのＣＴＳ受信トリガの処理はモジュール５０８で実行される。最小限の帯域幅のベアラのためのベアラ変更をトリガする決定がモジュール５０８で決定されると、制御はシグナリングインタフェース５１８を通じてモジュール５０９へ渡される。モジュール５０９では、トリガの決定が行われ、ＮＡＳレイヤ５０３は、最小限の帯域幅の専用レイヤのためのベアラ変更を送信するよう要求される。モジュール５０９からＮＡＳレイヤ５０３へのトリガは、シグナリングインタフェース５１７経由で実行される。
＜デバイスの動作のフローチャート＞
　次に図６を参照しながら、本発明の好適な実施の形態におけるモバイルデバイスの動作について説明する。第１ステップとして、チェックプロセス６００がトリガされ、モバイルデバイス（ＭＴＣデバイスであってもよい）は、高優先度及び広帯域幅トラフィックを転送するための広帯域幅ベアラが必要か否かをチェックする。こうしたチェックは、ステップ６００で実行される。このステップ６００によって、高優先度及び広帯域トラフィックが送信される必要があるかどうかが特定される。このステップ６００が『いいえ』の場合には、ステップ６０１が実行される。ステップ６０１は、高優先度トラフィック及び広帯域幅トラフィックを通知するための新たな情報要素が付加されることのなく、通常のサービス要求をトリガする通常の処理を有している。また、ステップ６００が『はい』の場合には、ステップ６０２が実行される。ステップ６０２では、高優先度トラフィックに関する新しい情報が付加されたサービス要求が作成されて送信される。ステップ６０２を実行した後、決定処理がトリガされる。この決定処理はステップ６０３によって示される。ステップ６０３では、高優先度トリガが付加されたサービス要求が受け入れられたかどうかがチェックされる。非常に稀にしか起こらないが、高優先度トラフィックに関する帯域幅を取得するために最小限の帯域幅のベアラのためのサービス要求が受け入れられなかった場合には、制御はステップ６０４に渡され、ＭＴＣデバイスは、後でサービス要求をリトライすることを決定する。
　ステップ６０３が『はい』であり、ＭＭＥがサービス要求応答によって最小限の帯域幅のベアラを提供する場合には、制御はステップ６０５に渡される。ステップ６０５では、ＭＴＣデバイスは、デフォルトベアラが与えられた場合にはベアラに関するＱＣＩを低減させ、最小限の帯域幅のベアラを使用して警告メッセージをＭＴＣサーバへ送信する。警告メッセージをＭＴＣサーバへ送信した後、ＭＴＣデバイスはＭＴＣサーバからのＣＴＳを待機し、ステップ６０６に示すようにＣＴＳ受信状態のチェック処理を実行する。ＣＴＳを受信すると、ステップ６０８が実行され、ＭＴＣデバイスは、デバイス始動ベアラ変更処理を使用して、最小限の帯域幅に係るＱＣＩを増加させるよう要求する。また、ステップ６０６が『いいえ』の場合には、ステップ６０７が実行され、ＭＴＣデバイスは単にＣＴＳを待機し続けるか、あるいは、利用可能な帯域幅を用いて緊急トラフィックに関連する情報をＭＴＣサーバへ送信する。
＜本発明が応用された派生例＞
　次に、本発明の好適な実施の形態に従った派生的な応用例について説明する。本発明の派生例は、コアネットワークが時間制御機能（Time Controlled）を実装しており、ＭＴＣデバイスが時間許容アプリケーションを有する構成において性能を拡張するために使用される。時間制御機能は、トラフィック伝送のためにネットワークを使用するＭＴＣデバイスのアクセス時間に係るネットワーク制御を表す。時間制御機能がネットワークに存在している場合、ＭＴＣデバイスが時間許容（Time Tolerant）アプリケーションを有するときには、この時間制御機能の影響をほとんど受けない。なお、時間許容及び時間制御の詳細は、非特許文献１に説明されている。ネットワークが時間制御メカニズムを動作しているとき、ネットワークは、ＭＴＣデバイスに対してこの状態を通知し、その結果、ＭＴＣデバイスは、時間制御期間の間はネットワークを通じてトラフィックを送信しない。なお、ほとんどの場合において、ＭＴＣサーバではなくＭＴＣデバイスのみが、この時間制御期間を把握している。時間制御期間が伝送される瞬間に、ネットワークが、ＭＴＣデバイス上の時間制御をＭＴＣデバイスへ課すことを決定した場合には、ＭＴＣデバイスは帯域幅を有さず、時間制御状態に関してＭＴＣサーバへ通知するためのアクセスさえ行わない。図７Ａを参照しながら、このような時間制御トラフィック伝送環境に本発明を適用した場合について説明する。
　本発明の派生的な応用例では、最小限の帯域幅のベアラを生成することによって、ＭＴＣデバイスは、輻輳状態又はコアネットワークにおける時間制御状態をＭＴＣサーバへ通知することが可能である。輻輳状態又は時間制御状態をＭＴＣサーバへ通知することによって、ＭＴＣサーバが、ネットワークによって時間制御されたＭＴＣデバイスへ、Ｕプレーントラフィックを送信しないようにすることが可能となる。ＭＴＣサーバは、このような時間制御状態においてＭＴＣデバイスへトラフィックを送信し続けるならば、ネットワークに複数の問題をもたらすことになる。第１の問題は、時間制御状態が取り除かれるまでダウンリンクトラフィックに必要となる格納リソースである。第２の問題は、バッファオーバフローによってデータが失われてしまうかもしれないという問題である。
　以下、図７Ａを参照しながら、応用例について説明する。図７Ａでは、ＭＴＣデバイス７０９、７０８、７０７、７０６がＰ－ＧＷ７０１を通じてＭＴＣサーバ７０２と通信を行っている。また、これらのＭＴＣデバイスは、ｅＮＢ７１０、Ｓ－ＧＷ７０４、ＭＭＥ７０５に接続されており、ＭＴＣサーバ７０２とグループ通信を行っているとする。上述のように、コアネットワーク７００及び／又はアクセスネットワーク７０３が輻輳状態である場合には、ネットワークは、Ｕプレーントラフィック送信のためにＭＴＣデバイスが３ＧＰＰネットワークへアクセスすることが禁止されていることをＭＴＣデバイスへ通知する。さらに、これらのＭＴＣデバイスは時間許容トラフィックを有しているとする。
　このような場合、ＭＴＣサーバ７０２は、時間制御条件を把握していないかもしれず、何らかの制御又はポーリングメッセージをこれらのＭＴＣデバイスへ送信してしまい、ネットワークリソースを浪費してしまうことになる。このような問題を解決するために、例えば、ＭＴＣデバイス７０９は、こうしたネットワークの時間制御状態の通知を受けた場合には、デフォルトベアラ７１２に加えて、最小限の帯域幅のベアラ７１１を生成するようネットワークへ要求することが可能である。このような最小限の帯域幅のベアラ７１１は、時間制御又は輻輳状態であることをＭＴＣサーバへ通知するためだけのものである。最小限の帯域幅のベアラ７１１を使用することで、ＭＴＣデバイス７０９は、メッセージをＭＴＣサーバ７０２へ送信し、時間制御状態であることを通知する。ＭＴＣサーバ７０２がこのような情報を処理するとき、ＭＴＣサーバ７０２は、時間制御期間が満了するまで、ＭＴＣデバイス７０９へのメッセージの送信を中止する。なお、時間制御ウィンドウが静的であるならば、ウィンドウ期間をＭＴＣサーバ７０２に通知することが可能である。一方、動的な時間制御ウィンドウ期間の場合には、ネットワークは、時間制御の満了の瞬間をランダムに通知し、ＭＴＣデバイス７０９は、最小限の帯域幅のベアラを使用して、時間制御の終了をＭＴＣサーバ７０２へ通知する。
　ＭＴＣデバイス７０９は、ＭＴＣサーバ７０２へのトラフィックの送信を再開すると、最小限の帯域幅のベアラに関してモバイルデバイス始動のベアラ変更処理を実行するか、新たな専用ベアラを要求し、この後使用するために休止モード（dormant mode）において最小限の帯域幅のベアラを保持する。
＜本発明の派生的な応用例の詳細な説明＞
　以下、図７Ｂを参照しながら、本発明のさらに別の派生的な応用例について説明する。ＭＴＣデバイス７００ａは、任意のネットワークセグメント７０１ａを使用してＭＴＣサーバ７０２ａと通信を行っている。この任意のネットワークセグメント７０１ａは、３ＧＰＰネットワークセグメントであってもよい。また、ネットワーク７０１ａは、加入しているＭＴＣデバイス上で何らかの時間制御を課しているとする。ここでは、時間制御は、ＭＴＣデバイスがある明確な期間の間はネットワーク７０１ａの使用を禁じられることを意味する。また、ネットワークに輻輳が発生している場合に、ネットワークが時間制御を課してもよい。ネットワーク７０１ａからＭＴＣデバイス７００ａへ送信される時間制御情報は、メッセージ７０３ａによって示されている。このメッセージ７０３ａは任意のタイプのメッセージを用いて送信されてもよい。３ＧＰＰ構成では、時間制御メッセージ７０３ａは、ページングトリガ、サービス要求受け入れ、あるいは、任意のＮＡＳメッセージによって送信可能であり、特定のメッセージに限定されるものではない。
　ＭＴＣデバイス７００ａは、このメッセージ７０３ａを確認すると、そのサーバ（ＭＴＣサーバ７０２ａ）と通信を行うための最小限の帯域幅のベアラを取得するため、サービス要求メッセージ７０４ａをネットワーク７０１ａへ送信する。最小限の帯域幅のベアラの要求７０４ａは、主に、ＭＴＣデバイス７００ａの時間制御状態をＭＴＣサーバ７０２ａへ通知するために実行される。ネットワーク７０１ａは、上述のように最小限の帯域幅のベアラを作成し、最小限の帯域幅のベアラのＩＤを有する応答メッセージ７０５ａをＭＴＣデバイス７００ａへ送信する。このようなＭＴＣデバイス７００ａへの応答メッセージと最小限の帯域幅のベアラの確立は、メッセージ７０５ａ、７０６ａによってそれぞれ示されている。
　ここで、時間制御が課される期間が、ＭＴＣサーバ７０２ａには知らされていないとする。このとき、ＭＴＣサーバ７０２ａからＭＴＣデバイス７００ａへ不要なトラフィックが送信されないようにするため、ＭＴＣデバイス７００ａは、最小限の帯域幅のベアラを使用して、Ｕプレーン警告メッセージをＭＴＣサーバ７０２ａへ送信する。このような警告メッセージは、メッセージ７０７ａによって示される。ＭＴＣサーバ７０２ａは、この警告メッセージを確認すると、適切な設定を行って、ＭＴＣデバイス７００ａへのＵプレーントラフィックを妨げるか又は中断する。これは、状態７０８ａに示される。また、ある時間経過した後、ネットワーク７０１ａは、ＭＴＣデバイス７００ａの時間制御を緩和する決定を行う。時間制御の緩和は、明示的なメッセージ７０９ａによって送信可能である。ネットワーク７０１ａは、時間制御期間を事前に把握している場合には、その期間情報をメッセージ７０３ａによって送信する。しかしながら、ほとんどの場合、ネットワーク７０１ａは、この時間制御の正確な期間を知らず、明示的なトリガ７０９ａによってＭＴＣデバイス７００ａに通知しようとする。ＭＴＣデバイス７００ａは、メッセージ７０９ａを受信すると、ＵプレーントラフィックをＭＴＣサーバ７０２ａへ送信するための最小限の帯域幅のベアラを拡張するよう、ネットワーク７０１ａへ要求する。このようなベアラ変更シグナリングは、メッセージ７１０ａ、７１１ａによって示されている。アップリンクのデータ送信はメッセージ７１２ａによって示され、ダウンリンクのデータメッセージはメッセージ７１４ａによって示される。
＜制御プレーンシグナリングを使用して、帯域幅が不足している状態をＭＴＣサーバへ通知する本発明の派生例＞
　上述の説明では、最小限の帯域幅のベアラが構成されると、ＭＴＣデバイスが最小限の帯域幅のベアラを使用して、Ｕプレーン警告メッセージをＭＴＣサーバへ送信する本発明の動作について説明した。このＵプレーン警告メッセージは、ＡｖＧｒＢＷが０であることを通知するため、又は、ＭＴＣデバイスが時間制御状態であることを通知するために使用可能である。このような時間制御又はＡｖＧｒＢＷが無い状態において最小限の帯域幅のベアラを割り当て、このベアラを使用してＭＴＣサーバへＵプレーン警告メッセージを送信することにはいくつかの利点がある。第１の利点は、このような最小限の帯域幅のベアラの割り当てによって、ＭＴＣデバイスが接続モードに切り換えられ、その結果、ＭＴＣサーバが送信可情報を通知しようとした場合に、より簡単にＭＴＣサーバがデバイスと通信を行えるようになるという点である。ＭＴＣデバイスが接続モードの場合、接続モードでページングを受信する際の遅延がなく、その結果、接続モードへの移行に関連した遅延が発生しないことから、ＭＴＣサーバからのメッセージの受信にほとんど時間を要さない。第２の利点は、ＭＴＣデバイスは接続モード時にはＭＴＣサーバから到達可能なので、ネットワークからのページングシグナリングや、ＭＴＣデバイスからのサービス要求シグナリングを回避できるようになる点である。第３の利点は、ＭＴＣデバイスはＵプレーン警告メッセージを使用してＭＴＣサーバへ通知を行うので、このメッセージは、別の手段（帯域メッセージ以外）又はＭＴＣサーバへのホップバイホップ転送を用いた場合よりも短い時間でＭＴＣサーバへ送信可能であるという点である。
　しかしながら、ＭＴＣサーバへ通信を行うことが可能であり、ＭＴＣデバイスのＡｖＧｒＢＷ＝０の状態を通知することが可能な帯域幅がないときには、ＭＴＣデバイスがその現在の緊急状態を制御プレーンシグナリングを用いてＭＴＣサーバへ通知し、依然としてアイドル状態のままでいることが有益となる場合もある。一般に、ＭＴＣデバイスがアイドルモードにあるときは、位置更新の頻度が小さく、ＭＴＣデバイスがハンドオフ管理のためのセルモニタリングを実行する必要がないので、電力消費が低いと考えられる。本発明の好適な実施の形態によれば、帯域幅が不足している状態にあること又は時間制御状態にあることに関する警告メッセージは、制御プレーンメッセージによってＭＴＣサーバへ通知される。
　本発明の別の実施例として、ＭＴＣデバイスが制御プレーンメッセージをネットワークへ送信し、帯域幅が不足している状態であること又は時間制御状態であることについて、ネットワークからＭＴＣサーバへ通知することが可能である。ＭＴＣサーバへ通知するためにＣプレーンメッセージを使用すると、ＭＴＣデバイスが接続モードとなる必要が無いという利点に加えて、ネットワークが何らかの別の手段を使用することで、コアネットワークを伝送させずにＭＴＣサーバと通信できるという別の利点がある。これは、特に、ネットワークが輻輳しているか、割り当てられるべき帯域がない場合に有用である。また、帯域幅が不足している状態（すなわち、ＡｖＧｒＢＷ＝０）、又は、輻輳による時間制御状態を通知するために制御プレーンを使用する更なる利点として、ＭＴＣデバイスとネットワークとの間のインタフェースでは、Ｕプレーンメッセージと比較して制御プレーンメッセージのパケットサイズが小さいという点も挙げられる。通常、レイヤ化されたプロトコルアーキテクチャによれば、Ｕプレーンメッセージのサイズは大きくなる。したがって、帯域幅制約環境の下で、制御プレーンシグナリングを使用してＭＴＣデバイスの警告状態をネットワークへ通知することは有用である。さらに、図８を参照しながら、本発明のシグナリング交換について説明する。
　図８において、ＭＴＣデバイス８００は、ネットワークセグメント８０１を経由してＭＴＣサーバ８０２と通信を行っている。このネットワークセグメント８０１は、３ＧＰＰネットワークであってもよいが、３ＧＰＰネットワークに限定されるものではない。このような構成において、ＭＴＣデバイス８００は高優先度、広帯域幅、リアルタイムＵプレーントラフィックをＭＴＣサーバ８０２へ送信しようとしているかもしれない。ＭＴＣデバイス８００は現在アイドルモードであり、この高優先度トラフィックを送信するために、ネットワーク８０１へのサービス要求メッセージ８０３の送信を行うとする。さらに、メッセージ８０３がネットワーク８０１で受信された場合にＡｖＧｒＢＷの値が０であるとする。なお、ネットワーク８０１が、メッセージ８０３を受信したときに、ＭＴＣデバイス８００に時間制御を課すよう決定したとしてもよい。上述のネットワーク状態において、ネットワーク８０１は、適切な項目を有するサービス要求拒絶メッセージ８０４を送信することが可能である。この拒絶項目は、例えば、ネットワークが、拒絶の理由がＡｖＧｒＢＷが十分ではないか、ネットワーク８０１において時間制御アクティブであるかのどちらであることを通知するものである。
　ＭＴＣデバイス８００は、メッセージ８０４を受信すると、Ｕプレーンメッセージを使用してＭＴＣサーバ８０２へ届くベアラがないことを把握し、アイドルモードのままとなる。また、メッセージ８０４の拒絶項目を受信した後、ＭＴＣデバイス８００は、決定処理を行って、ネットワーク８０１へＣプレーンメッセージを送信することを決定する。このＣプレーンメッセージは、ＭＴＣデバイス８００の状態をＭＴＣサーバ８０２へ通知するよう要求するものである。このＣプレーンメッセージは、ネットワーク８０１が３ＧＰＰネットワークである場合には、ＴＡＵであってもよく、また、任意のＮＡＳメッセージであってもよい。Ｃプレーンメッセージ８０５には、ＡｖＧｒＢＷ＝０の状態に関する情報、又は時間制御状態に関する情報が埋め込まれている。また、メッセージ８０５には、このような状態情報がＭＴＣサーバ８０２へ渡される必要性に関する情報も含まれている。ネットワークエンティティ８０１は、制御メッセージ８０５を受信し、別の新たな制御メッセージ８０６をＭＴＣサーバ８０２へ送信する。制御メッセージ８０６には、ＭＴＣデバイス８００の状態情報が含まれている。なお、メッセージ８０６は、ネットワーク８０１及びＭＴＣサーバ８０２を接続しているコアネットワークを経由して送信される必要はなく、別のネットワークを通じてメッセージ８０６を送信することが可能である。
　ＡｖＧｒＢＷが０であることを通知するためのメッセージ８０６がＭＴＣサーバ８０２へ送信された場合、ＭＴＣサーバ８０２は、上述のように、ＭＴＣデバイス８００のために何らかの利用可能な帯域幅を取得しようと試みる。ＭＴＣサーバ８０２は、ＭＴＣデバイス８００のための帯域幅を取得すると、ＣＴＳメッセージ８０７をＭＴＣデバイス８００へ送信することが可能となる。ＭＣＴデバイス８００は、前回サービス要求を行ったときにネットワーク８０１によって無線ベアラが割り当てられておらず、アイドルモードなので、ネットワーク８０１は、ページングメッセージ８０８をＭＴＣデバイス８００へ送信する。ページングメッセージ８０８を受信すると、ＭＴＣデバイス８００は、サービス要求メッセージ８０９を送信し、接続モードへ移行する。サービス要求８０９が受け入れられ、ＭＴＣデバイス８００が接続モードへ移行し、すべての無線ベアラがセットアップされると、ＭＴＣデバイス８００は、ネットワーク８０１にバッファされているＣＴＳメッセージ８０７を受信することが可能となる。
　さらに、ＭＴＣサーバ８０２がＡｖＧｒＢＷに付加されている何らかの帯域幅を取得したことにより、ＡｖＧｒＢＷが０より大きいので、ネットワーク８０１は、サービス要求受け入れメッセージ８１０をＭＴＣデバイス８００へ送信する。このサービス要求受け入れメッセージ８１０は、高優先度、広帯域幅、リアルタイムトラフィックを転送するための適切な帯域幅が利用可能であることに関する通知を有していてもよい。サービス要求が受け入れられることは、無線ベアラがＭＴＣデバイス８００のためにセットアップされることを意味する。さらに、ＣＴＳメッセージ８０７が無線ベアラを通じてＭＴＣデバイス８００へ送信されるとする。ＣＴＳメッセージ８０７を受信すると、ＭＴＣデバイス８００は、適切なベアラを使用して、ＵプレーントラフィックをＭＴＣサーバ８０２へ送信できるようになる。なお、ＭＴＣサーバ８０２へのＵプレーントラフィック送信は、メッセージ８１１によって示される。
　また、ＡｖＧｒＢＷが０より大きい場合、ネットワーク８０１は、ＣＴＳメッセージ８０７を待機せずにページングメッセージを送信することも可能である。また、別の派生的な応用例では、ＭＴＣデバイス８００は、このようなトリガをサービス要求メッセージ８０３に挿入することにより、緊急トラフィックに関する警告メッセージを送信することが可能である。また、ＡｖＧｒＢＷが０ならば、サービス要求８０３が挿入された警告メッセージの処理が行われた後、制御プレーンメッセージがＭＴＣサーバ８０２へ送信される。
　なお、本発明は、最も実用的かつ好適な実施の形態であると考えられるものを示し、説明を行っているが、当業者であれば、本発明の範囲から逸脱しない程度にデザイン及びパラメータの詳細について様々な派生例が存在することが分かるであろう。
　また、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
　また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
　さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
　本発明は、パケット交換型データ通信ネットワークにおける通信技術に関する。本発明は、特に、グループベースの通信において、グループに帯域幅の上限（グループ帯域幅上限値）が設定されている場合の技術に適用可能である。また、本発明は、特に、マシントゥーマシン通信及びマシンタイプ通信の技術に適用可能である。

Claims (12)

  1. 　複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置のそれぞれに割り当てられている通信のビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける通信装置であって、
    　高優先度及び高ビットレートのトラフィックの送信を行うかどうか決定する送信決定部と、
    　前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した場合、前記高優先度及び高ビットレートのトラフィックの送信を行うためのサービス要求を前記ネットワークへ送信するサービス要求送信部と、
    　前記サービス要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックを送信することができないベアラのベアラ識別子を含むサービス要求応答を受信するサービス要求応答受信部と、
    　前記ベアラ識別子によって特定されるベアラを経由して、前記高優先度及び高ビットレートのトラフィックの送信要求を前記特定の通信サーバへ送信するトラフィック送信要求部と、
    　前記トラフィックの送信要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックの送信が可能かどうかを示す情報を含む送信要求応答を受信するトラフィック送信要求応答受信部と、
    　前記送信要求応答から、前記高優先度及び高ビットレートのトラフィックの送信が可能であると判断された場合には、前記高優先度及び高ビットレートのトラフィックを前記特定の通信サーバへ送信するトラフィック送信部とを、
    　有する通信装置。
  2. 　前記サービス要求応答に含まれる前記ベアラ識別子が、最小限の帯域幅を有するベアラを示すものであり、前記トラフィック送信要求部は、前記ベアラ識別子によって識別される前記最小限の帯域幅を有するベアラを経由して、前記トラフィックの送信要求を前記特定の通信サーバへ送信するよう構成されている請求項１に記載の通信装置。
  3. 　前記サービス要求応答に含まれる前記ベアラ識別子が、デフォルトベアラを示すものであり、前記トラフィック送信要求部は、前記ベアラ識別子によって識別される前記デフォルトベアラを経由して、前記トラフィックの送信要求を前記特定の通信サーバへ送信するよう構成されている請求項１に記載の通信装置。
  4. 　前記送信要求応答から、前記高優先度及び高ビットレートのトラフィックの送信が可能であると判断された場合には、前記ベアラ識別子によって特定されるベアラを経由して前記高優先度及び高ビットレートのトラフィックを前記特定の通信サーバへ送信することが可能となるように、前記ベアラ識別子によって特定されるベアラの帯域幅を変更する処理を行うベアラ変更部を有し、
    　前記トラフィック送信部が、前記ベアラ変更部によって帯域幅が変更された前記ベアラ識別子によって特定されるベアラを経由して前記高優先度及び高ビットレートのトラフィックを前記特定の通信サーバへ送信するよう構成されている請求項１に記載の通信装置。
  5. 　前記トラフィック送信要求部が、前記高優先度及び高ビットレートのトラフィックの送信要求を、ユーザプレーン又は制御プレーンのどちらかのメッセージを利用して前記特定の通信サーバへ送信するよう構成されている請求項１に記載の通信装置。
  6. 　複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置が前記特定の通信サーバと行っている前記通信のそれぞれのビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける前記ネットワークを構成するネットワークノードであって、
    　前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置から、前記高優先度及び高ビットレートのトラフィックの送信を行うためのサービス要求を受信するサービス要求受信部と、
    　前記サービス要求に対する応答として、前記高優先度及び高ビットレートのトラフィックを送信することができないベアラのベアラ識別子を含むサービス要求応答を送信するサービス要求応答送信部とを、
    　有するネットワークノード。
  7. 　前記高優先度及び高ビットレートのトラフィックの送信を仮に許可した場合に前記システム内のビットレートの総和が前記所定の上限値を超えてしまわないかどうかをチェックする上限値超過チェック部と、
    　前記上限値超過チェック部で前記総和が前記所定の上限値を超えないと判断された場合には、前記高優先度及び高ビットレートのトラフィックを送信することができるベアラのベアラ識別子を含むサービス要求応答を送信する送信するサービス要求許可応答送信部とを、
    　有し、
    　前記上限値超過チェック部で前記総和が前記所定の上限値を超えてしまうと判断された場合にのみ、前記サービス要求応答送信部が、前記サービス要求に対する応答として、前記高優先度及び高ビットレートのトラフィックを送信することができないベアラのベアラ識別子を含むサービス要求応答を送信するよう構成されている請求項６に記載のネットワークノード。
  8. 　前記上限値超過チェック部で前記総和が前記所定の上限値を超えてしまうと判断された場合に、前記通信装置が前記高優先度及び高ビットレートのトラフィックの送信要求を前記特定の通信サーバへ送信するためのベアラを設定するための処理を、前記ネットワークを構成する他のネットワークノードとの間で実行するベアラ設定処理部を有し、
    　前記サービス要求応答送信部が、前記サービス要求に対する応答として、前記ベアラ設定処理部で設定を行ったベアラのベアラ識別子を含むサービス要求応答を送信するよう構成されている請求項７に記載のネットワークノード。
  9. 　前記サービス要求応答に含まれる前記ベアラ識別子が、最小限の帯域幅を有するベアラを示すものである請求項６に記載のネットワークノード。
  10. 　前記サービス要求応答に含まれる前記ベアラ識別子が、デフォルトベアラを示すものである請求項６に記載のネットワークノード。
  11. 　複数の通信装置が特定の通信サーバとネットワークを介して通信を行っているシステムであり、前記複数の通信装置のそれぞれに割り当てられている通信のビットレートの総和が、所定の上限値を超えることができないように設定されている前記システムにおける通信サーバであって、
    　高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置から、所定のベアラを経由して前記高優先度及び高ビットレートのトラフィックの送信要求を受信するトラフィック送信要求受信部と、
    　前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置以外の通信装置のうち、トラフィックの送信を中止させることができる特定の通信装置に対して、トラフィックの中止指示を送信するトラフィック中止指示部と、
    　前記トラフィック中止指示部によってトラフィックの送信が中止された特定の通信装置に割り当てられていた帯域幅を、前記高優先度及び高ビットレートのトラフィックの送信を行うことを決定した前記通信装置によるトラフィック用に予約し、前記トラフィックの送信要求に対する応答であって、前記高優先度及び高ビットレートのトラフィックの送信が可能であることを示す情報を含む送信要求応答を送信するトラフィック送信要求応答送信部とを、
    　有する通信サーバ。
  12. 　前記トラフィックの送信を中止させることができる前記特定の通信装置を特定するために、前記複数の通信装置のそれぞれによって送信されているトラフィックの優先度を判断する優先度判断部を有する請求項１１に記載の通信サーバ。
PCT/JP2011/002264 2010-04-30 2011-04-19 通信装置、ネットワークノード並びに通信サーバ WO2011135800A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2012512648A JP5718322B2 (ja) 2010-04-30 2011-04-19 通信装置、ネットワークノード並びに通信サーバ
US13/643,637 US9143461B2 (en) 2010-04-30 2011-04-19 Communication device, network node, and communication server

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2010105195 2010-04-30
JP2010-105195 2010-04-30

Publications (1)

Publication Number Publication Date
WO2011135800A1 true WO2011135800A1 (ja) 2011-11-03

Family

ID=44861126

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/002264 WO2011135800A1 (ja) 2010-04-30 2011-04-19 通信装置、ネットワークノード並びに通信サーバ

Country Status (3)

Country Link
US (1) US9143461B2 (ja)
JP (1) JP5718322B2 (ja)
WO (1) WO2011135800A1 (ja)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2493917A (en) * 2011-08-19 2013-02-27 Sca Ipla Holdings Inc Transmitting data via mtc type terminals in a multicast transmission
WO2013081759A1 (en) * 2011-11-29 2013-06-06 Motorola Solutions, Inc. Method and apparatus for managing quality of service settings for group communications
WO2013108870A1 (ja) * 2012-01-20 2013-07-25 シャープ株式会社 通信システム、ゲートウェイ装置及び通信方法
WO2013119375A1 (en) * 2012-02-07 2013-08-15 Qualcomm Incorporated Data radio bearer (drb) enhancements for small data transmissions apparatus, systems, and methods
US8965415B2 (en) 2011-07-15 2015-02-24 Qualcomm Incorporated Short packet data service
JP2015520965A (ja) * 2012-05-11 2015-07-23 インテル・コーポレーション マシンタイプコミュニケーションユーザ機器の無線セルへの選択的参加
JP2016195448A (ja) * 2016-07-13 2016-11-17 京セラ株式会社 基地局およびその制御方法
JP2017521953A (ja) * 2014-07-15 2017-08-03 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ ＰｒｏＳｅ直接発見のためのベアラ管理
JP2019503119A (ja) * 2015-12-04 2019-01-31 ソニー株式会社 ネットワーク利用率を向上させるためのネットワーク支援プロトコルの使用

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11202178B2 (en) * 2011-05-09 2021-12-14 Apple Inc. Techniques for machine-to-machine device management
EP2544467B1 (en) * 2011-07-04 2018-12-19 Koninklijke KPN N.V. Triggering with time indicator
EP2608567A1 (en) * 2011-12-13 2013-06-26 Panasonic Corporation Device triggering and congestion control
CN104584598B (zh) * 2012-03-27 2018-04-27 爱立信(中国)通信有限公司 确定内容数据网络的内容数据源与终端之间的数据业务的业务承载
US9015395B2 (en) * 2012-05-10 2015-04-21 Alcatel Lucent Methods and apparatuses for multiple priority access in a wireless network system
US9107183B2 (en) * 2012-08-31 2015-08-11 Qualcomm Incorporated Providing group call priority access in LTE and priority access for user equipments with dual access classes
US9655159B2 (en) 2012-08-31 2017-05-16 Qualcomm Incorporated Managing guaranteed bit rate quality of service resource allocation based on guaranteed bit rate data activity on a link
US8929899B2 (en) * 2012-12-12 2015-01-06 At&T Intellectual Property I, L.P. Long term evolution mobility network timer and retry management
CN103906262B (zh) * 2012-12-26 2019-02-26 中兴通讯股份有限公司 一种承载分配方法及用户设备、基站和服务网关
US10834557B2 (en) 2013-02-13 2020-11-10 Aeris Communications, Inc. Layered machine to machine (M2M) service methodology using class-based access point names (APNs) for the internet of things
US9215549B2 (en) 2013-02-13 2015-12-15 Aeris Communications, Inc. Method for delivering machine to machine (M2M) application control data over control plane in LTE/EPS utilizing standard bearer management procedures
US20140273956A1 (en) * 2013-03-15 2014-09-18 Jim S. Baca Motion initiated teleconference
JP2014204193A (ja) * 2013-04-02 2014-10-27 株式会社Ｎｔｔドコモ 移動通信システム
US10034229B2 (en) 2013-06-13 2018-07-24 Telefonaktiebolaget Lm Ericsson (Publ) Methods, apparatus, network node, and computer program product for dynamically providing CDN service through mobile network
US9301245B2 (en) * 2013-06-14 2016-03-29 Qualcomm Incorporated Toll path routing protocol
JP6239280B2 (ja) * 2013-06-27 2017-11-29 京セラ株式会社 ユーザ端末、プロセッサ及び移動通信システム
WO2015043662A1 (en) * 2013-09-27 2015-04-02 Telefonaktiebolaget L M Ericsson (Publ) Methods, devices and computer programs for providing a service or service component requiring a specific packet-forwarding treatment
US9094450B2 (en) * 2013-11-01 2015-07-28 Xerox Corporation Method and apparatus for a centrally managed network virus detection and outbreak protection
EP3128706B1 (en) * 2014-04-29 2022-09-21 Huawei Technologies Co., Ltd. Resource reuse method and apparatus
US9554392B2 (en) 2014-10-15 2017-01-24 At&T Intellectual Property I, L.P. Machine to machine traffic management methods and systems
US9609660B2 (en) * 2014-12-19 2017-03-28 Wipro Limited System and method for adaptive downlink scheduler for wireless networks
EP3873013A1 (en) 2015-01-30 2021-09-01 Sony Group Corporation Adaptive index mapping for low order modulation scheme settings
CN106171031B (zh) * 2015-02-11 2020-04-21 华为技术有限公司 组通信中组优先级通知方法、设备及系统
US10574833B2 (en) * 2015-02-26 2020-02-25 Nokia Solutions And Networks Oy Charging and control of edge services
CN107683626B (zh) * 2015-05-20 2021-11-05 瑞典爱立信有限公司 用于根据ue的应用需求在无线网络中预调度上行链路资源的节点和方法
US10484273B2 (en) * 2015-08-05 2019-11-19 Microsoft Technology Licensing, Llc Notification for a prioritized media path for a communication session
US9961712B2 (en) * 2015-10-27 2018-05-01 Verizon Patent And Licensing Inc. Connection and traffic management in a multiple core network architecture
US10129689B2 (en) 2015-11-02 2018-11-13 Definition Networks, Inc. Systems and methods for machine-type communication
US11115793B2 (en) * 2016-08-04 2021-09-07 At&T Mobility Ii Llc LTE gateways for home and commercial sensor data
US10070302B2 (en) * 2016-08-30 2018-09-04 Verizon Patent And Licensing Inc. Internet of things (IoT) delay tolerant wireless network service
US11418998B2 (en) * 2018-04-17 2022-08-16 Telefonaktiebolaget Lm Ericsson (Publ) Wireless device, network node, core node and methods for handling radio communication of data
EP3811661A4 (en) * 2018-06-25 2022-01-26 Telefonaktiebolaget LM Ericsson (publ) PROCEDURES AND NETWORK NODES TO SUPPORT A SERVICE VIA A RADIO CARRIER
US10735209B2 (en) * 2018-08-08 2020-08-04 Cisco Technology, Inc. Bitrate utilization feedback and control in 5G-NSA networks
US11373506B1 (en) * 2020-01-09 2022-06-28 II Luis Baradas Buena Independent security monitoring device and process for monitoring infrastructure systems by way of an artificial intelligence and sensor-based location-independent device
EP4243374A4 (en) * 2020-12-04 2024-04-10 Samsung Electronics Co., Ltd. METHOD AND APPARATUS FOR PERFORMING A RADIO ACCESS NETWORK FUNCTION
US11444896B1 (en) * 2021-04-09 2022-09-13 Slack Technologies, Llc Real-time feedback for message composition in a communication platform

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003333050A (ja) * 2002-05-10 2003-11-21 Matsushita Electric Ind Co Ltd データ送信方法
JP2004356855A (ja) * 2003-05-28 2004-12-16 Tdk Corp 無線ネットワークシステム
JP2010050550A (ja) * 2008-08-19 2010-03-04 Oki Electric Ind Co Ltd 通信システム、並びに、通信帯域制御装置、プログラム及び方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7133403B1 (en) 2000-05-05 2006-11-07 Fujitsu Limited Transport network and method
US7408948B2 (en) 2001-04-17 2008-08-05 Nokia Corporation Packet mode speech communication
US7958532B2 (en) * 2001-06-18 2011-06-07 At&T Intellectual Property Ii, L.P. Method of transmitting layered video-coded information
WO2006087817A1 (ja) 2005-02-21 2006-08-24 Fujitsu Limited 通信制御システム
US7609634B2 (en) 2005-03-22 2009-10-27 Alcatel Lucent Communication traffic policing apparatus and methods
JP4869888B2 (ja) * 2006-11-29 2012-02-08 京セラ株式会社 無線通信端末装置
US8498651B2 (en) * 2009-11-06 2013-07-30 Alcatel Lucent Method of call admission control for home femtocells

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003333050A (ja) * 2002-05-10 2003-11-21 Matsushita Electric Ind Co Ltd データ送信方法
JP2004356855A (ja) * 2003-05-28 2004-12-16 Tdk Corp 無線ネットワークシステム
JP2010050550A (ja) * 2008-08-19 2010-03-04 Oki Electric Ind Co Ltd 通信システム、並びに、通信帯域制御装置、プログラム及び方法

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8965415B2 (en) 2011-07-15 2015-02-24 Qualcomm Incorporated Short packet data service
US9585122B2 (en) 2011-08-19 2017-02-28 Sca Ipla Holdings Inc Telecommunications apparatus and methods
US10652857B2 (en) 2011-08-19 2020-05-12 Convida Wireless, Llc Telecommunications apparatus and methods
GB2493917A (en) * 2011-08-19 2013-02-27 Sca Ipla Holdings Inc Transmitting data via mtc type terminals in a multicast transmission
US10200972B2 (en) 2011-08-19 2019-02-05 Sca Ipla Holdings Inc. Telecommunications apparatus and methods
GB2493917B (en) * 2011-08-19 2016-04-06 Sca Ipla Holdings Inc Telecommunications apparatus and methods for multicast transmissions
WO2013081759A1 (en) * 2011-11-29 2013-06-06 Motorola Solutions, Inc. Method and apparatus for managing quality of service settings for group communications
GB2510090A (en) * 2011-11-29 2014-07-23 Gill Jennings & Every Llp Method and apparatus for managing quality of service settings for group communications
US9173134B2 (en) 2011-11-29 2015-10-27 Motorola Solutions, Inc. Method and apparatus for managing quality of service settings for group communications
GB2510090B (en) * 2011-11-29 2018-08-01 Motorola Solutions Inc Method and apparatus for managing quality of service settings for group communications
WO2013108870A1 (ja) * 2012-01-20 2013-07-25 シャープ株式会社 通信システム、ゲートウェイ装置及び通信方法
CN104054324A (zh) * 2012-01-20 2014-09-17 夏普株式会社 通信系统、网关装置以及通信方法
US8660078B2 (en) 2012-02-07 2014-02-25 Qualcomm Incorporated Data radio bearer (DRB) enhancements for small data transmissions apparatus, systems, and methods
WO2013119375A1 (en) * 2012-02-07 2013-08-15 Qualcomm Incorporated Data radio bearer (drb) enhancements for small data transmissions apparatus, systems, and methods
JP2015520965A (ja) * 2012-05-11 2015-07-23 インテル・コーポレーション マシンタイプコミュニケーションユーザ機器の無線セルへの選択的参加
JP2017521953A (ja) * 2014-07-15 2017-08-03 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ ＰｒｏＳｅ直接発見のためのベアラ管理
US10433284B2 (en) 2014-07-15 2019-10-01 Qualcomm Incorporated Bearer management for prose direct discovery
JP2019503119A (ja) * 2015-12-04 2019-01-31 ソニー株式会社 ネットワーク利用率を向上させるためのネットワーク支援プロトコルの使用
JP2016195448A (ja) * 2016-07-13 2016-11-17 京セラ株式会社 基地局およびその制御方法

Also Published As

Publication number Publication date
US9143461B2 (en) 2015-09-22
US20130051326A1 (en) 2013-02-28
JPWO2011135800A1 (ja) 2013-07-18
JP5718322B2 (ja) 2015-05-13

Similar Documents

Publication Publication Date Title
JP5718322B2 (ja) 通信装置、ネットワークノード並びに通信サーバ
JP7416368B2 (ja) 時間依存ネットワーキングのための制御プレーンに基づく設定
US10499326B2 (en) User equipment paging method and MME
JP7455138B2 (ja) コアページング処理
US8861535B2 (en) Multi-tiered paging support using paging priority
TWI580298B (zh) 用於在無線通信系統中監控ｕｅ可達性的方法及設備
CN106961456B (zh) 决定iot业务方法和设备、iot业务行为控制方法和设备
US10200908B2 (en) Methods, apparatus, a system, and a related computer program product for activation and deactivation of bearers
US9794969B2 (en) Bearer allocation method, user equipment, base station, and serving gateway
KR101877589B1 (ko) 이동 통신 네트워크, 인프라스트럭처 장비, 이동 통신 장치 및 방법
US9713042B2 (en) Method and system for notifying attribute of IP address and SGW
US20150358967A1 (en) Method and Device for Adjusting Radio Resource
US20220264444A1 (en) Session Management for A Network Slice
CN102612096B (zh) 一种ip数据包的传输方法和设备
CN106162930A (zh) 在设备直通系统中承载的管理方法和装置
WO2013189348A2 (zh) 一种承载分配和管理的方法及设备
US20190260857A1 (en) Data Packet Processing Method, Control Plane Network Element, And User Plane Network Element
WO2012024989A1 (zh) 承载释放方法及系统
WO2010054544A1 (zh) 一种移动通讯分组域演进系统中寻呼的方法
CN114631397A (zh) 无线网络中的信令传送
WO2017031763A1 (zh) 一种语音业务建立方法、装置及设备
CN102056247A (zh) 一种限制mtc设备组最大比特率的方法和接入网关
CN103108358B (zh) 一种小数据传输方法及装置、系统
WO2019034021A1 (zh) 一种异系统互操作的方法及装置

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012512648

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13643637

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 11774589

Country of ref document: EP

Kind code of ref document: A1