WO2018066668A1 - Ｓｃｅｆエンティティ、通信端末、データ処理方法、データ受信方法、及び非一時的なコンピュータ可読媒体 - Google Patents

Ｓｃｅｆエンティティ、通信端末、データ処理方法、データ受信方法、及び非一時的なコンピュータ可読媒体 Download PDF

Info

Publication number
WO2018066668A1
WO2018066668A1 PCT/JP2017/036380 JP2017036380W WO2018066668A1 WO 2018066668 A1 WO2018066668 A1 WO 2018066668A1 JP 2017036380 W JP2017036380 W JP 2017036380W WO 2018066668 A1 WO2018066668 A1 WO 2018066668A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
scef
communication
buffered
communication terminal
Prior art date
Application number
PCT/JP2017/036380
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 EP21167314.0A priority Critical patent/EP3883271A1/en
Priority to CN201780061580.7A priority patent/CN109891918B/zh
Priority to US16/339,808 priority patent/US10911936B2/en
Priority to EP17858504.8A priority patent/EP3525497B1/en
Priority to JP2018543973A priority patent/JP6733736B2/ja
Publication of WO2018066668A1 publication Critical patent/WO2018066668A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H04W28/14—Flow control between communication endpoints using intermediate storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/20—Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/24—Interfaces between hierarchically similar devices between backbone network devices
    • 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/741—Holding a request until resources become available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/005—Routing actions in the presence of nodes in sleep or doze mode
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H04W92/14—Interfaces between hierarchically different network devices between access point controllers and backbone network device
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Definitions

  • the present invention relates to an SCEF (Service Capability Exposure Function) entity, a communication terminal, a data processing method, a data receiving method, and a program.
  • SCEF Service Capability Exposure Function
  • a communication terminal a data processing method
  • a data receiving method a data receiving method
  • a program a program that processes Non-IP data
  • IoT Internet of Things
  • devices devices
  • One challenge in providing a device with a mobile communication function is to reduce power consumption. It is expected to operate without maintenance for a long period of several years, such as sensor devices. In order to provide such a device with a mobile communication function, it is desirable to reduce communication power consumption.
  • Non-IP data delivery that performs data communications without using the IP protocol stack is defined as one of the technologies to reduce the power consumption of communications. Yes.
  • Non-Patent Document 1 discloses a configuration example for performing non-IP data delivery on a downlink (from the network to the terminal) in an EPC (Evolved Packet Core) network, and a procedure in the configuration example. .
  • EPC Evolved Packet Core
  • a UE UserUEEquipment
  • SCS Service Capability Server
  • AS Application Server
  • C Control
  • NAS Non Access Stratum
  • communication in the downlink may be temporarily unreachable (UE is unreachable) depending on the UE power save mode status, radio wave status, and the like.
  • UE unreachable
  • NIDD Submit Request Non-IP data delivery request
  • the MME detects that the UE is unreachable, it returns a response (NIDD Submit Response) to the Non-IP data delivery delivery request, including a Cause indicating that the Non-IP data was not delivered to the UE.
  • NIDD Submit Response a response to the Non-IP data delivery delivery request, including a Cause indicating that the Non-IP data was not delivered to the UE.
  • the MME notifies the SCEF of the fact (NIDD: Submit Indication). Indicates to do.
  • the SCEF that has received the above response buffers the Non-IP data until NIDD Submit Indication is sent from the MME.
  • SCEF finally retransmits the Non-IP data delivery delivery request triggered by the reception of NIDD-Submit-Indication from the MME.
  • the SCEF receives a Non-IPUEdata delivery transmission request for the second Non-IP data from the SCS or AS while the SCEF is buffering the first Non-IP data because the UE is unreachable Sometimes.
  • the SCEF transmits a Non-IP data delivery transmission request regarding the second Non-IP data to the MME. Since the UE is unreachable, the second Non-IP data does not reach the UE and is buffered in the SCEF similarly to the first Non-IP data. Therefore, in a situation where the UE is unreachable, the SCEF transmitting a Non-IP data delivery transmission request for the second Non-IP data has an adverse effect of increasing the SCEF-MME communication processing.
  • An object of the present invention is to provide an SCEF entity, a communication terminal, a data processing method, a data receiving method, and a program for suppressing an increase in processing load related to communication between SCEF and MME in Non-IP data delivery. It is in.
  • the SCEF entity includes a storage unit that buffers first Non-IP data that has not been delivered to a communication terminal, and a second Non-IP that is addressed to the communication terminal from a server device.
  • a storage unit that buffers first Non-IP data that has not been delivered to a communication terminal, and a second Non-IP that is addressed to the communication terminal from a server device.
  • the second Non-IP data is suppressed from being transmitted to the control device in the mobile network, and the second Non-IP data is suppressed.
  • a control unit that buffers non-IP data in the storage unit.
  • the communication terminal provides a plurality of Non-IP soot data buffered by the SCEF entity until the device can be reached via the control device when the device becomes reachable.
  • the first Non-IP data that has not been delivered to the communication terminal is buffered, and the second Non-IP data destined for the communication terminal is received from the server device.
  • the second Non-IP data is suppressed from being transmitted to the control device in the mobile network, and the second Non-IP data is suppressed. Data is buffered.
  • a plurality of Non-IP soup data buffered by the SCEF entity until the own device can be reached, when the own device becomes reachable, via the control device. are received as one message, and a plurality of Non-IP data included in the one message is read for each Non-IP data.
  • a program buffers first Non-IP data that has not been delivered to a communication terminal, and receives second Non-IP data destined for the communication terminal from a server device.
  • the second Non-IP data is suppressed from being transmitted to the control device in the mobile network, and the second Non-IP data is transmitted. It causes the computer to perform the buffering.
  • an SCEF entity it is possible to provide an SCEF entity, a communication terminal, a data processing method, a data receiving method, and a program that suppress an increase in processing load related to communication between SCEF and MME in Non-IP data delivery. .
  • FIG. 1 is a configuration diagram of a communication system according to a first exemplary embodiment
  • FIG. 3 is a configuration diagram of a communication system according to a second exemplary embodiment. It is a figure which shows the flow of a process when UE concerning Embodiment 2 is unreachable. It is a figure which shows the flow of a process when UE concerning Embodiment 2 is reachable. It is a figure which shows the flow of a process in which SCEF concerning Embodiment 3 receives the information regarding an allowable communication amount and a rate. It is a block diagram of UE concerning Embodiment 4. FIG. It is a figure which shows the flow of a process when UE concerning Embodiment 4 is reachable.
  • the communication system of FIG. 1 includes a service capability exposure function (SCEF) entity (hereinafter referred to as SCEF) 10, a control device 20, a server device 30, and a communication terminal 40.
  • SCEF service capability exposure function
  • the SCEF 10, the control device 20, the server device 30, and the communication terminal 40 may be computer devices that operate when a processor executes a program stored in a memory.
  • the communication terminal 40 may be a mobile phone terminal, a smartphone terminal, a tablet terminal, or the like.
  • the communication terminal 40 may be an M2M (Mobile to Mobile) terminal, an MTC (Machine Type to Communication) terminal, an IoT (Internet of Things) terminal, or the like.
  • the communication terminal 40 communicates with the SCEF entity 10 via a radio access network.
  • the server device 30 may be, for example, an application server that provides application services.
  • the server device 30 may be a server device that is arranged between the application server and the SCEF 10 and relays data related to the application service.
  • the control device 20 is a node device arranged in the mobile network.
  • the control device 20 is a node device that relays or processes control information in the mobile network.
  • the control information may be referred to as C (Control) -Plane data, C-Plane message, and the like, for example.
  • the control device 20 may be, for example, an MME or SGSN (Serving GPRS (General Packet Radio Service) Support Node) defined in 3GPP.
  • SCEF10 is a node device whose operation is defined in 3GPP.
  • SCEF10 is a mobile network specified in 3GPP, and is arranged between a mobile network managed by a mobile communication carrier and a server device managed by a third party other than the mobile communication carrier such as an application server. Is done.
  • the SCEF 10 securely provides the server device 30 with information about services that can be handled in the mobile network and the ability to provide the services.
  • Non-IP data is data that does not use the IP protocol stack.
  • Non-IP data refers to data packets used for communication that are not structured from the perspective of EPS (Evolved Packet System).
  • EPS Evolved Packet System
  • technologies commonly called “LPWA (Low Power Wide Area)” such as LoRa, “SIGFOX” and “NB-IoT” do not establish an IP data bearer in order to reduce the power consumption of the device.
  • Non-IP Data Delivery (NIDD)
  • NIDD Non-IP Data Delivery
  • Non-IP data is transmitted as control information in the mobile network.
  • Non-IP data may be, for example, data transmitted to an IoT terminal that receives an IoT service.
  • the SCEF 10 includes a storage unit 11 and a control unit 12.
  • the control unit 12 may be software or a module that executes processing when the processor executes a program stored in a memory.
  • the control unit 12 may be hardware such as a chip or a circuit.
  • the storage unit 11 may be a memory, for example.
  • the storage unit 11 buffers Non-IP data that has not been delivered to the communication terminal 40. In other words, the storage unit 11 temporarily stores, saves, or stores the Non-IP data before retransmitting the Non-IP data to the communication terminal 40.
  • the case where the non-IP data is not delivered to the communication terminal 40 includes, for example, a case where the communication terminal 40 is in a power save mode, or a case where radio communication cannot be performed due to deterioration of radio wave conditions.
  • the state in which the non-IP data is not delivered to the communication terminal 40 may be rephrased as the communication terminal 40 being unreachable. Further, the state in which the Non-IP data can be delivered to the communication terminal 40 may be rephrased as the communication terminal 40 being reachable.
  • control unit 12 When the control unit 12 receives Non-IP data destined for the communication terminal 40 from the server device 30 and the non-IP data that has not been delivered to the communication terminal 40 is buffered in the storage unit 11, The transmission of the Non-IP data received from the device 30 to the control device 20 in the mobile network is suppressed, and the Non-IP data received from the server device 30 is buffered in the storage unit 11. Suppressing transmission of Non-IP data to the control device 20 in the mobile network includes not transmitting Non-IP data to the control device 20 in the mobile network.
  • the case where the Non-IP data that has not been delivered to the communication terminal 40 is buffered in the storage unit 11 is a case where the communication terminal 40 is unreachable. Therefore, even if new non-IP data destined for the communication terminal 40 received by the SCEF 10 from the server device 30 is transmitted to the control device 20, the control device 20 transmits the non-IP data to the communication terminal 40. There is a high possibility that non-IP data cannot be transmitted to the communication terminal 40.
  • control unit 12 generates unnecessary traffic in the mobile network by buffering the non-IP data received from the server device 30 in the storage unit 11 without transmitting it to the control device 20. This can be prevented.
  • the communication system of FIG. 2 includes SCEF 10, MME 22, SGSN 24, RAN (Radio Access Network) 26, AS 32, SCS 34, and UE 42.
  • the MME 22 and the SGSN 24 correspond to the control device 20 in FIG.
  • the AS 32 and the SCS 34 correspond to the server device 30 in FIG.
  • the UE 42 corresponds to the communication terminal 40 in FIG. UE42 is used as a general term for communication terminals in 3GPP.
  • the RAN 26 may be, for example, an eNB (evolved Node E B) that supports LTE (Long Term Term Evolution) communication, and an RNC that controls Node B and Node B that support radio communication defined as 3G communication in 3GPP. Radio Network Controller).
  • eNB evolved Node E B
  • LTE Long Term Term Evolution
  • RNC Radio Network Controller
  • the MME 22 and the SGSN 24 may be referred to as a CPF (C-Plane Function) entity (hereinafter referred to as CPF).
  • CPF C-Plane Function
  • the MME 22 and the SGSN 24 are devices that mainly perform UE 42 mobility management, bearer setting request, bearer setting instruction, bearer deletion request, or bearer deletion instruction.
  • AS32 and SCS34 are devices used to provide application services to UE42.
  • the application service may be referred to as an IoT service, for example.
  • the AS 32 or the SCS 34 transmits Non-IP data to the SCEF 10.
  • the AS 32 may transmit Non-IP data directly to the SCEF 10 without going through the SCS 34.
  • AS32 or SCS34 may be described as AS32 / SCS34 or SCS34 / AS32 in the following description.
  • the SCEF 10 transmits the Non-IP data transmitted from the SCS 34 / AS 32 to the MME 22 or the SGSN 24.
  • the MME 22 or the SGSN 24 delivers Non-IP data to the UE 42 via the RAN 26.
  • the MME 22 or the SGSN 24 returns Non-IP data to the SCEF 10 when the UE 42 is unreachable.
  • the SCEF 10 buffers Non-IP data that has not been delivered to the UE 42.
  • FIG. 2 shows a configuration in which the SCEF 10, the MME 22, the RAN 26, and the SGSN 24 belong to an HPLMN (Home Public Land Mobile Mobile Network).
  • HPLMN Home Public Land Mobile Mobile Network
  • SCEF10 belongs to HPLMN and MME22, SGSN24, and RAN26 belong to VPLMN (Visited PLMN)
  • IWK (Interworking) -SCEF is arranged between SCEF10 and MME22 and between SCEF10 and SGSN24. May be.
  • the IWK-SCEF is arranged in the VPLMN, and relays communication between the SCEF 10 and the MME 22 and further communication between the SCEF 10 and the SGSN 24.
  • the SCEF 10 describes the process of delivering Non-IP data via the MME 22, but the SGSN 24 may be used instead of the MME 22.
  • the SCS 34 / AS 32 transmits a NIDD Submit Request message to the SCEF 10 (S11).
  • the NIDD Submit Request message includes an External Identifier or MSISDN (Mobile Subscriber Integrated Service Digital Digital Network Number).
  • MSISDN Mobile Subscriber Integrated Service Digital Digital Network Number
  • the NIDD Submit Request message includes SCS / AS Reference ID and Non-IP data.
  • the External Identifier and MSISDN are identification information of the UE 42.
  • SCS / AS Reference ID is identification information of SCS34 or AS32.
  • the SCEF 10 when the SCEF 10 receives the NIDD Submit Request message from the SCS 34 / AS 32, the SCEF 10 confirms whether there is an SCEF EPS bearer context associated with the External Identifier or MSISDN (S12). Further, when the SCEF 10 receives the NIDD / Submit / Request message from the SCS 34 / AS 32, the SCEF 10 confirms whether the SCS 34 / AS 32 is authorized to transmit the NIDD / Submit / Request message (S12). Further, when the SCEF 10 receives the NIDD Submit Request message from the SCS 34 / AS 32, the SCEF 10 confirms whether at least one of the allowable traffic and rate of the Non-IP data permitted by the SCS 34 / AS 32 has been exceeded (S12). .
  • the allowable communication amount may be, for example, a cumulative value of the amount of data transmitted per day.
  • SCEF EPS bearer text is information indicating that a bearer for transmitting Non-IP data is established between the MME 22 and the SCEF 10.
  • T6a is defined as a reference point in 3GPP.
  • the bearer between MME22 and SCEF10 is established at the time of UE42 Attach processing.
  • SGSN 24 may be used instead of MME 22.
  • T6b is defined as a reference point in 3GPP.
  • the SCEF EPS bearer of the UE 42 is a bearer set between the SCEF 10 and the MME 22 for transmitting Non-IP data between the UE 42 and the SCS 34 / AS 32.
  • SCEF10 does not have SCEF EPS bearer context
  • SCS34 / AS32 is not authorized to send NIDD SubmitRequest message
  • SCS34 / AS32 allows non-IP data allowable traffic and rate If it corresponds to at least one event of exceeding at least one, an NIDD Submit Response message is transmitted to the SCS 34 / AS 32 (S13).
  • the information that caused the NIDD Submit Response message to be sent is set in the NIDD Submit Response message.
  • the information that caused the NIDD Submit ⁇ Response message to be transmitted may be indicated using a cause value set in the NIDD Submit Response message, for example.
  • the SCEF 10 may discard the Non-IP soot data received in step S11 if it exceeds at least one of the allowable communication amount and rate of Non-IP data permitted by the SCS 34 / AS 32.
  • the SCEF 10 may discard the excess non-IP data.
  • the SCEF 10 exceeds the non-IP data rate permitted by the SCS 34 / AS 32, the SCEF 10 discards some of the non-IP data and controls the rate so as to obtain the permitted rate. Good.
  • the SCEF 10 when there is no SCEF EPS bearer context associated with the External Identifier or MSISDN, the SCEF 10 establishes Non-IP PDN connection with the MME that manages the UE corresponding to the External Identifier or MSISDN. May be executed.
  • the SCEF 10 has SCEF EPS bearer context, the SCS34 / AS32 is authorized to send the NIDD Submit Request message, and the allowed non-IP data allowed for the SCS34 / AS32 If the rate is not exceeded, the control unit 12 of the SCEF 10 determines whether another Non-IP data to be transmitted to the SCEF EPS bearer of the UE 42 is already buffered in the storage unit 11 (S14). .
  • Another Non-IP data to be transmitted to the SCEF EPS bearer of the UE 42 may be Non-IP data that has not been delivered to the UE 42, for example.
  • the SCEF 10 sends an NIDD Submit Request message to the MME 22 ( S15).
  • the NIDD Submit Request message includes User Identity, EPS (Evolved Packet System) Bearer ID, SCEF ID, Non-IP data, SCEF Wait Time, and Maximum Re-transmission time.
  • User Identity is identification information of the UE 42.
  • EPS bearer ID is identification information of a bearer (SCEF EPS bearer) set between SCEF10 and MME22.
  • SCEF ID is identification information of SECF10.
  • SCEF Wait Time is a time during which the SCEF 10 can wait for a Response message transmitted from the MME 22.
  • Maximum Re-transmission time is the time during which the SCEF 10 can retransmit the message.
  • the MME 22 detects that the UE 42 is unreachable (S16).
  • the MME 22 transmits a NIDD Submit Response message to the SCEF (S17).
  • the NIDD Submit Response message includes Cause and Requested Re-transmission Time.
  • the Cause indicates that the Non-IP data has not been delivered to the UE 42 because the UE 42 is temporarily unreachable because the UE 42 is in the power saving mode, and that the UE has become reachable (UE is reachable).
  • a content indicating that the MME 22 notifies the SCEF 10 of the fact is set.
  • Requested Re-transmission Time indicates the time when the SCEF 10 is predicted to be able to retransmit downlink data to the UE 42 that is currently unreachable.
  • the MME 22 when the MME 22 detects that the UE is reachable (UE is reachable), the MME 22 sets a Not-Reachable-for-NIDD flag indicating that the SCEF 10 is notified.
  • the SCEF 10 when the SCEF 10 receives the NIDD Submit Response message from the MME 22, the SCEF 10 understands that the UE 42 is unreachable with reference to a Cause value indicating that the UE 42 is temporarily not reachable because it is in the power saving mode. To do. Further, the SCEF 10 buffers the Non-IP data that was attempted to be transmitted in step S15 (S18). Further, when the SCEF 10 determines in step S14 that another Non-IP data to be transmitted to the SCEF EPS bearer of the UE 42 has already been buffered in the storage unit 11, the processing of steps S15 to S17 is executed. Instead, the non-IP data received in step S11 is buffered (S18).
  • the SCEF 10 transmits an NIDD Submit Response message including the result received from the MME 22 to the SCS 34 / AS 32 (S19).
  • the NIDD Submit Response message may include information indicating that the SCEF 10 has buffered the Non-IP data received in step S11 without transmitting it to the MME 22, or temporarily because the UE 42 is in the power saving mode. Information indicating that it is not reachable may be included.
  • the MME 22 detects that the UE 42 is reachable or reachable (S21). For example, the MME 22 detects that the UE 42 is reachable when the UE 42 returns from the power saving mode by executing TAU (Tracking Area Update), or when Mobile Originated communication is started.
  • TAU Track Area Update
  • the MME 22 sends a NIDD Submit Indication message to the SCEF 10 that sent the NIDD Submit Response message in step S17 of FIG. 3 (S22).
  • the NIDD Submit Indication message includes User Identity.
  • User Identity is identification information of the UE 42.
  • the SCEF 10 transmits the buffered Non-IP data to the MME 22 using the NIDD Submit Request message in the buffered order (S23). For example, if the SCEF 10 determines in step S14 in FIG. 3 that another Non-IP data to be transmitted to the SCEF EPS bearer of the UE 42 is already buffered in the storage unit 11, it is already buffered first. Non-IP data is transmitted to the MME 22. Thereafter, the SCEF 10 transmits the Non-IP data received in step S11 of FIG.
  • SCEF 10 transmits Non-IP data to MME 22 and transmits it to SCEFAEPS bearer of UE 42
  • SCEF 10 communicates so as not to exceed the allowable traffic and rate of Non-IP data allowed by SCS 34 / AS 32. Apply quantity and rate control. That is, the SCEF 10 applies the communication amount and rate control not only when the Non-IP data is transmitted to the MME 22 at Step S15 in FIG. 3 but also when the Non-IP data is transmitted at Step S23 in FIG. .
  • the MME 22 delivers Non-IP data to the UE 42 (S24). For example, if a C-Plane connection is being established between the UE 42 and the MME 22, the MME 22 immediately transmits Non-IP data to the UE 42. If the C-Plane connection is not established between the UE 42 and the MME 22, a paging process for calling the UE 42 is performed. MME22 will transmit Non-IP data to UE42, if C-Plane connection is established between UE42 by performing a paging process.
  • the MME 22 transmits a NIDD Submit Response message to the SCEF 10 (S25).
  • the NIDD-Submit-Response message includes a cause value indicating that delivery of Non-IP data could be started.
  • the SCEF 10 transmits the NIDD Submit Response message received from the MME 22 to the SCS 34 / AS 32 (S26).
  • steps S23 to S26 are repeatedly performed according to the number of buffered Non-IP data. That is, the SCEF 10 transmits a NIDD Submit Request message to the MME 22 for each buffered Non-IP data.
  • step S23 when the SCEF 10 transmits the Non-IP data to the MME 22, the non-permitted non-permitted amount of the non-IP data permitted by the SCS 34 / AS 32 and the rate permitted by the SCEF 10 are transmitted.
  • the communication amount and rate may be controlled so as not to exceed the allowable amount and rate of IP data.
  • the SCEF 10 can determine whether or not Non-IP data to be transmitted to the UE 42 is buffered. Further, when the SCEF 10 determines that the Non-IP data to be transmitted to the UE 42 is buffered, the SCEF 10 buffers the Non-IP data without performing the NIDD-Submit-Request message transmission process and the NIDD-Submit-Response message reception process. can do. Thereby, it is possible to avoid occurrence of unnecessary traffic between the SCEF 10 and the MME 22.
  • the SCEF 10 sends the buffered Non-IP data to the MME 22 to the SCEFSCEPS bearer of the UE 42
  • the SCEF 10 sends the previously buffered Non-IP data to the MME 22 to the SCEF EPS bearer of the UE 42. Can be sent. Accordingly, it is possible to avoid the UE 42 from reversing the order of receiving the Non-IP data. As a result, it is possible to provide an application service that is required to maintain the order of Non-IP data.
  • the SCEF 10 transmits the buffered Non-IP data to the SCME EPS bearer of the UE 42 to the MME 22, the allowable communication amount and rate of the Non-IP data allowed by the SCS 34 / AS32 or the SCEF 10 Traffic volume and rate control can be applied so as not to exceed. As a result, it is possible to avoid occurrence of burst transfer when the SCEF 10 retransmits the Non-IP data. As a result, it is possible to reduce or avoid an event in which the UE 42 such as a low-performance IoT device in terms of communication speed fails to receive Non-IP data.
  • the SCEF 10 applies the communication amount and rate control so as not to exceed the allowable communication amount and rate of Non-IP data permitted by the SCS 34 / AS 32.
  • the communication amount and rate control are applied so as not to exceed the allowable communication amount and rate of the Non-IP data allowed for the UE 42 or the SCEF EPS bearer of the UE 42.
  • the SCEF EPS bearer of the UE 42 is a bearer set between the SCEF 10 and the MME 22 for transmitting Non-IP data between the UE 42 and the SCS 34 / AS 32.
  • the SCS 34 / AS 32 transmits a NIDD Configuration Request message to the SCEF 10 (S31).
  • the NIDD Configuration Request message contains an External Identifier or MSISDN.
  • the External Identifier or MSISDN is information for identifying the UE 42.
  • the NIDD Configuration Request message includes an SCS / AS Reference ID.
  • the SCEF 10 stores the External Identifier or MSISDN included in the NIDD Configuration Request message and the SCS / AS Reference ID in the storage unit 11 (S32).
  • the SCEF 10 sends an NIDD Authorization Request message to the HSS (Home Subscriber Server) to confirm whether the SCS 34 / AS32 is authorized to send the NIDDNIConfiguration Request message related to the received External Identifier or MSISDN. (S33).
  • the NIDD Authorization Request message includes an External Identifier or MSISDN and an APN (Access Point Name) associated with the SCEF 10.
  • the HSS is a node device that manages subscriber information regarding a plurality of UEs.
  • the HSS determines that the SCS 34 / MME 22 is authorized to transmit the NIDD Configuration Request message (S34). Further, the HSS extracts an IMSI (International Mobile Subscriber Identity) associated with an External Identifier or MSISDN included in the NIDD Authorization Authorization message. The IMSI is used as UE identification information in the mobile network.
  • IMSI International Mobile Subscriber Identity
  • the HSS transmits a NIDD Authorization Response message to the SCEF 10 as a response to the NIDD Authorization Request message (S35).
  • the NIDD Authorization Response message contains the IMSI associated with the External Identifier or MSISDN.
  • the NIDD Authorization Response message includes LoadControlInformation indicating at least one of the allowed communication amount and rate of Non-IP data allowed for the UE 42. It is assumed that the HSS manages, as subscriber information, at least one of the allowable traffic and rate of Non-IP data allowed for each UE or for each SCEF EPS bearer of the UE.
  • the SCEF 10 transmits an NIDD Configuration Response message to the SCS 34 / AS 32 as a response to the NIDD Configuration Request message (S36).
  • the SCEF 10 can acquire information indicating at least one of the allowable traffic and rate of Non-IP data allowed for the UE 42 from the HSS. Or SCEF10 can acquire the information which shows at least one of the allowable communication amount and rate of Non-IP data permitted by SCEF
  • the SCEF 10 can transmit Non-IP data to the UE 42 according to the same sequence as that in FIG. However, the SCEF 10 allows the UE 42 or the SCEFMEEPS bearer of the UE 42 to transmit the Non-IP data to the MME 22 to the SCEF EPS bearer of the UE 42 in Step S15 of Fig. 3 and Step S23 of Fig. 4.
  • the traffic volume and rate control are applied so as not to exceed the permitted traffic volume and rate of the non-IP data.
  • the SCEF 10 transmits the buffered Non-IP data to the MME 22 to the SCEF EPS bearer of the UE 42
  • the SCEF 10 is permitted to the UE 42 or the SCEF EPS bearer of the UE 42.
  • Traffic volume and rate control can be applied so as not to exceed the allowable traffic volume and rate of IP data.
  • the UE 42 such as a low-performance IoT device in terms of communication speed can reduce or avoid an event in which the reception of Non-IP data fails.
  • the UE 42 includes a communication unit 43 and a control unit 44.
  • the communication unit 43 and the control unit 44 may be software or a module that executes processing when the processor executes a program stored in a memory.
  • the communication unit 43 and the control unit 44 may be hardware such as a chip or a circuit.
  • the communication unit 43 receives Non-IP data delivered from the MME 22.
  • the communication unit 43 receives a plurality of non-IP data using one message. That is, the MME 22 does not repeat transmission of Non-IP data the same number of times as the number of Non-IP data buffered in the SCEF 10, but transmits one message including a plurality of Non-IP data to the UE.
  • the communication unit 43 outputs one message including a plurality of non-IP data to the control unit 44.
  • the control unit 44 reads a plurality of Non-IP data included in one message for each Non-IP data. In other words, the control unit 44 reads a plurality of Non-IP data included in one message for each Non-IP data. In other words, the control unit 44 parses and reads a plurality of Non-IP data included in one message.
  • the control unit 44 may hold information on the data size of Non-IP data, for example. For example, information related to the data size of each Non-IP data may be set in one message including a plurality of Non-IP data. Alternatively, when the data size of the Non-IP data is predetermined in the mobile network, the control unit 44 may hold information regarding the data size of the predetermined Non-IP data. The control unit 44 may read a plurality of Non-IP data included in one message according to the data size of the Non-IP data.
  • Steps S41 and S42 in FIG. 7 are the same as steps S21 and S22 in FIG.
  • the SCEF 10 transmits a plurality of buffered non-IP data to the MME 22 using one NIDD Submit Request message to the SCEF EPS bearer of the UE 42 ( S43). For example, the SCEF 10 sets the first buffered Non-IP data in the data area near the beginning of the NIDD Submit Request message, and the newly buffered Non-IP data in the data area near the tail of the message. It may be set.
  • the MME 22 delivers the plurality of Non-IP data to the UE 42 using one message (S44).
  • the MME 22 transmits a NIDD Submit Response message to the SCEF 10 (S45).
  • the SCEF 10 transmits an NIDD Submit Response message to the SCS 34 / AS 32 for each Non-IP data (S46 and S47).
  • the SCEF 10 transmits the first buffered Non-IP data # 1 and the later buffered Non-IP data # 2 to the MME 22 using one NIDD Submit Request message. .
  • the SCEF 10 when the SCEF 10 receives the NIDD Submit Response message, the SCEF 10 transmits the NIDD Submit ⁇ ⁇ Response message indicating that the Non-IP data # 1 has been delivered to the UE 42 in step S46, and delivers the Non-IP data # 2 to the UE 42.
  • An NIDD Submit Response message indicating this is transmitted in step S47.
  • the SCEF 10 delivers a plurality of Non-IP data to the MME 22 using one NIDD Submit Request message to the SCEF EPS bearer of the UE 42. Can do.
  • the MME 22 can deliver a plurality of Non-IP data to the UE 42 using one message.
  • the UE 42 can read a plurality of Non-IP data included in one message for each Non-IP data.
  • the Non-IP data when the Non-IP data is information indicating the state of the UE 42, only new Non-IP data may be required. Specifically, when the UE 42 is a lamp, the Non-IP data may include information indicating whether the lamp state is turned ON or OFF. First, when Non-IP data indicating that the lamp state is to be turned off is transmitted from the SCS 34 / AS 32 to the SCEF 10 after Non-IP data indicating that the lamp state is to be turned ON is stored in the buffer. Non-IP data stored in the buffer is not required.
  • the SCEF 10 may delete the Non-IP data stored in the buffer first and buffer only the Non-IP data transmitted from the SCS 34 / AS 32 to the SCEF 10 later.
  • FIG. 8 shows Non-IP data buffered before step S11 of FIG. 3 is transmitted.
  • FIG. 9 shows the Non-IP data buffered in step S18 of FIG.
  • Non-IP data with a buffer order of 2 in FIG. 8 indicates that the switch of the device is turned on.
  • an attribute ID is set for each Non-IP data. For example, for Non-IP data whose buffer order is 2, information indicating a lamp state is set as an attribute ID.
  • the SCEF 10 may delete the already buffered Non-IP data.
  • FIG. 9 shows that when the non-IP data whose buffer order is 2 and the attribute ID of the newly received Non-IP data match in the ramp state, the already buffered Non-IP data is deleted. It shows that you are doing.
  • SCEF 10 when SCEF 10 buffers Non-IP data, it can delete unnecessary Non-IP data that is already buffered Non-IP data. Thereby, the buffer size of SCEF10 can be reduced.
  • FIG. 10 is a block diagram illustrating a configuration example of the UE 42.
  • Radio-frequency (RF) transceiver 1101 performs analog RF signal processing to communicate with RAN 26.
  • Analog RF signal processing performed by the RF transceiver 1101 includes frequency up-conversion, frequency down-conversion, and amplification.
  • RF transceiver 1101 is coupled with antenna 1102 and baseband processor 1103. That is, the RF transceiver 1101 receives modulation symbol data (or OFDM symbol data) from the baseband processor 1103, generates a transmission RF signal, and supplies the transmission RF signal to the antenna 1102. Further, the RF transceiver 1101 generates a baseband received signal based on the received RF signal received by the antenna 1102 and supplies this to the baseband processor 1103.
  • modulation symbol data or OFDM symbol data
  • the baseband processor 1103 performs digital baseband signal processing (data plane processing) and control plane processing for wireless communication.
  • Digital baseband signal processing consists of (a) data compression / decompression, (b) data segmentation / concatenation, (c) ⁇ transmission format (transmission frame) generation / decomposition, and (d) transmission path encoding / decoding.
  • E modulation (symbol mapping) / demodulation
  • IFFT Inverse Fast Fourier Transform
  • control plane processing includes layer 1 (eg, transmission power control), layer 2 (eg, radio resource management, hybrid automatic repeat request (HARQ) processing), and layer 3 (eg, attach, mobility, and call management). Communication management).
  • the digital baseband signal processing by the baseband processor 1103 includes signal processing of Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, MAC layer, and PHY layer. But you can. Further, the control plane processing by the baseband processor 1103 may include Non-Access Stratum (NAS) protocol, RRC protocol, and MAC ⁇ CE processing.
  • PDCP Packet Data Convergence Protocol
  • RLC Radio Link Control
  • MAC Medium Access Stratum
  • PHY Packet Data Convergence Protocol
  • the control plane processing by the baseband processor 1103 may include Non-Access Stratum (NAS) protocol, RRC protocol, and MAC ⁇ CE processing.
  • NAS Non-Access Stratum
  • the baseband processor 1103 includes a modem processor (eg, Digital Signal Processor (DSP)) that performs digital baseband signal processing and a protocol stack processor (eg, Central Processing Unit (CPU) that performs control plane processing, or Micro Processing Unit. (MPU)).
  • DSP Digital Signal Processor
  • protocol stack processor eg, Central Processing Unit (CPU) that performs control plane processing, or Micro Processing Unit. (MPU)
  • CPU Central Processing Unit
  • MPU Micro Processing Unit.
  • a protocol stack processor that performs control plane processing may be shared with an application processor 1104 described later.
  • the application processor 1104 is also called a CPU, MPU, microprocessor, or processor core.
  • the application processor 1104 may include a plurality of processors (a plurality of processor cores).
  • the application processor 1104 is a system software program (Operating System (OS)) read from the memory 1106 or a memory (not shown) and various application programs (for example, a call application, a web browser, a mailer, a camera operation application, music playback)
  • OS Operating System
  • the baseband processor 1103 and the application processor 1104 may be integrated on a single chip, as indicated by the dashed line (1105) in FIG.
  • the baseband processor 1103 and the application processor 1104 may be implemented as one System on Chip (SoC) device 1105.
  • SoC System on Chip
  • An SoC device is sometimes called a system Large Scale Integration (LSI) or chipset.
  • the memory 1106 is a volatile memory, a nonvolatile memory, or a combination thereof.
  • the memory 1106 may include a plurality of physically independent memory devices.
  • the volatile memory is, for example, Static Random Access Memory (SRAM), Dynamic RAM (DRAM), or a combination thereof.
  • the non-volatile memory is a mask Read Only Memory (MROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, hard disk drive, or any combination thereof.
  • the memory 1106 may include an external memory device accessible from the baseband processor 1103, the application processor 1104, and the SoC 1105.
  • Memory 1106 may include an embedded memory device integrated within baseband processor 1103, application processor 1104, or SoC 1105.
  • the memory 1106 may include a memory in a Universal Integrated Circuit Card (UICC).
  • UICC Universal Integrated Circuit Card
  • the memory 1106 may store a software module (computer program) including an instruction group and data for performing processing by the UE 42 described in the plurality of embodiments.
  • the baseband processor 1103 or the application processor 1104 may be configured to perform the processing of the UE 42 described in the above-described embodiment by reading the software module from the memory 1106 and executing the software module.
  • FIG. 11 is a block diagram illustrating a configuration example of the SCEF 10.
  • the SCEF 10 includes a network interface 1201, a processor 1202, and a memory 1203.
  • the network interface 1201 is used to communicate with a network node (e.g., MME 22 or SGSN 24).
  • the network interface 1201 may include, for example, a network interface card (NIC) compliant with IEEE 802.3 series.
  • NIC network interface card
  • the processor 1202 reads the software (computer program) from the memory 1203 and executes it, thereby performing the processing of the SCEF 10 described with reference to the sequence diagram and the flowchart in the above-described embodiment.
  • the processor 1202 may be, for example, a microprocessor, MPU, or CPU.
  • the processor 1202 may include a plurality of processors.
  • the memory 1203 is configured by a combination of a volatile memory and a nonvolatile memory.
  • Memory 1203 may include storage located remotely from processor 1202. In this case, the processor 1202 may access the memory 1203 via an I / O interface not shown.
  • the memory 1203 is used for storing software module groups.
  • the processor 1202 can perform the processing of the SCEF 10 described in the above-described embodiment by reading these software module groups from the memory 1203 and executing them.
  • each of the processors included in the UE 42 and the SCEF 10 in the above-described embodiment includes one or a plurality of instructions for causing a computer to execute the algorithm described with reference to the drawings. Run the program.
  • This program can be stored and supplied to a computer using various types of non-transitory computer readable media.
  • Non-transitory computer readable media include various types of tangible storage media (tangible storage medium).
  • non-transitory computer-readable media are magnetic recording media (eg flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (eg magneto-optical discs), Compact Disc Read Only Memory (CD-ROM), CD-ROM R, CD-R / W, semiconductor memory (for example, mask ROM, Programmable ROM (PROM), Erasable PROM (EPROM), flash ROM, Random Access Memory (RAM)).
  • the program may also be supplied to the computer by various types of temporary computer-readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves.
  • the temporary computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.
  • the controller is When the second Non-IP data is received from the server device, it is determined whether or not the first Non-IP data is buffered, and the first Non-IP data is buffered.
  • the second Non-IP is sent to the controller.
  • the SCEF entity according to appendix 1 which transmits data.
  • the controller is When receiving a message indicating that non-IP data can be delivered to the communication terminal from the control device, the control unit controls the first and second Non-IP data buffered in the storage unit.
  • the controller is The SCEF entity according to appendix 3, wherein the non-IP data buffered in the storage unit is transmitted to the control device in the order buffered in the storage unit.
  • the controller is The SCEF entity according to appendix 3 or 4, wherein one message including a plurality of non-IP data buffered in the storage unit is transmitted to the control device.
  • the controller is The SCEF entity according to any one of appendices 3 to 5, wherein the SCEF entity transmits the first and second Non-IP data to the control device so as to satisfy a communication amount or a communication rate allowed for the server device. .
  • the controller is When the second Non-IP data destined for the communication terminal is received from the server device and the communication amount or communication rate allowed for the server device is exceeded, the second Non-IP data The SCEF entity according to any one of appendices 1 to 6, which discards IP data.
  • the controller is Transmitting the first and second Non-IP data to the control device so as to satisfy a communication amount or a communication rate permitted by a communication bearer that transmits the Non-IP data by the communication terminal or the communication terminal;
  • the SCEF entity according to any one of appendices 3 to 5.
  • the controller is When the second Non-IP data destined for the communication terminal is received from the server device, the communication amount permitted by the communication terminal or a communication bearer that transmits the Non-IP data by the communication terminal or The SCEF entity according to any one of appendices 1 to 8, wherein when the communication rate is exceeded, the second Non-IP data is discarded.
  • the controller is The communication terminal or the communication terminal receives information on a communication amount or a communication rate allowed for the communication bearer transmitting Non-IP data from a subscriber information management device arranged in the mobile network, The SCEF entity according to appendix 8 or 9.
  • the controller is The SCEF entity according to any one of appendices 3 to 5, wherein the SCEF entity transmits the first and second Non-IP data to the control device so as to satisfy a communication amount or a communication rate allowed for the SCEF entity. .
  • the controller is When the second Non-IP data destined for the communication terminal is received from the server device and the communication amount or communication rate allowed for the SCEF entity is exceeded, the second Non-IP data The SCEF entity according to any one of appendices 1 to 11, which discards IP data.
  • the controller is When the second Non-IP data is Non-IP data for updating the first Non-IP data indicating the state of the communication terminal, the first Non-IP data is deleted from the storage unit The SCEF entity according to any one of appendices 1 to 12, wherein the second Non-IP data is buffered in the storage unit.
  • (Appendix 14) A communication unit that receives a plurality of Non-IP data buffered by the SCEF entity until the device becomes reachable, as a single message via the control device when the device becomes reachable; And a control unit that reads a plurality of Non-IP data included in the one message for each Non-IP data. (Appendix 15) Buffer the first Non-IP data that was not delivered to the communication terminal, When the second Non-IP data destined for the communication terminal is received from the server device, if the first Non-IP data is buffered, the second Non-IP data is stored in the mobile network. A data processing method for suppressing transmission to the control device and buffering the second non-IP data.
  • (Appendix 16) Receive multiple non-IP data buffered by the SCEF entity until the local device is reachable as a single message via the control device when the local device is reachable.
  • (Appendix 17) Buffer the first Non-IP data that was not delivered to the communication terminal, When the second Non-IP data destined for the communication terminal is received from the server device, if the first Non-IP data is buffered, the second Non-IP data is stored in the mobile network.
  • Appendix 18 Receive multiple non-IP data buffered by the SCEF entity until the local device is reachable as a single message via the control device when the local device is reachable.
  • Control Unit 10 SCEF 11 Storage Unit 12
  • Control Unit 20 Control Device 22
  • MME 24 SGSN 26
  • server device 32 AS 34 SCS 40 communication terminal 42
  • UE 43 Communication unit 44
  • Control unit 40 Control Unit 40

Landscapes

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

Abstract

Non-IPデータ通信において、ＳＣＥＦとＭＭＥとの間の通信に関する処理負荷が増大することを抑えるＳＣＥＦエンティティを提供することを目的とする。本発明にかかるＳＣＥＦエンティティ（１０）は、通信端末（４０）へ配送されなかった第１のNon-IPデータをバッファする記憶部（１１）と、サーバ装置（３０）から通信端末（４０）を宛先とする第２のNon-IPデータを受信した際に、第１のNon-IPデータがバッファされている場合、第２のNon-IPデータをモバイルネットワーク内の制御装置（２０）へ送信することを抑制し、前記第２のNon-IPデータを記憶部（１１）にバッファする制御部（１２）と、を備える。

Description

ＳＣＥＦエンティティ、通信端末、データ処理方法、データ受信方法、及び非一時的なコンピュータ可読媒体
　本発明はＳＣＥＦ（Service Capability Exposure Function）エンティティ、通信端末、データ処理方法、データ受信方法、及びプログラムに関し、例えば、Non-IP データを処理するＳＣＥＦエンティティ、通信端末、データ処理方法、データ受信方法、及びプログラムに関する。
　近年、様々なデバイス（モノ）にモバイル通信機能を持たせ、インターネットに接続したり、デバイス間で通信したりすることを実現するＩｏＴ（Internet of Things）に関するモバイル通信技術が発展している。デバイスにモバイル通信機能を持たせる上でのひとつの課題として、消費電力の低減がある。センサー装置など、数年単位の長期間に渡りメンテナンスフリーで稼働することが期待される。このようなデバイスにモバイル通信機能を持たせる上で、通信の消費電力を低減することが望ましい。
　モバイル通信に関する標準仕様を定める３ＧＰＰ（3rd Generation Partnership Project）においては、通信の消費電力を低減する技術の１つとして、ＩＰプロトコルスタックを使用せずデータ通信を行うNon-IP data deliveryが規定されている。
　非特許文献１の5.13.3節には、EPC（Evolved Packet Core）ネットワークにおいて、downlink（ネットワークから端末方向）のNon-IP data deliveryを行う構成例と、その構成例における手順が開示されている。
　この構成例は、Non-IPデータを受信するＵＥ（User Equipment）と、Non-IPデータの送信元であるＳＣＳ（Services Capability Server）又はＡＳ（Application Server）と、Non-IPデータを受け付けて認可と通信量制御及びレート制御（load control）を行うＳＣＥＦ（Service Capability Exposure Function）と、Ｃ（Control）－Ｐｌａｎｅのメッセージ（例えば、ＮＡＳ（Non Access Stratum）メッセージ）を用いてNon-IPデータをＵＥへ送信する交換局ＭＭＥ（Mobility Management Entity）と、を含む。
3GPP TS 23.682 V14.1.0 (2016-09) 5.13.3節
　モバイル通信において、downlink（ネットワークから端末方向）の通信は、ＵＥのパワーセーブモード状況、電波状況などにより、一時的に、ＵＥに到達不能（UE is unreachable）の場合がある。非特許文献１の5.13.3節には、downlink（ネットワークから端末方向）のNon-IP data deliveryを行う手順において、downlinkの通信がＵＥに到達不能だった場合に、ＵＥに到達可能となった後に、Non-IP data deliveryが行われる。
　ＭＭＥは、Non-IP data delivery送信リクエスト（NIDD Submit Request）をＳＣＥＦから受信する。ＭＭＥは、ＵＥに到達不能であることを検出した場合、Non-IPデータがＵＥへ配送されなかったことを示すCauseを含めて、Non-IP data delivery送信リクエストに対する応答（NIDD Submit Response）をリターンする。Non-IP data delivery送信リクエストに設定されるCauseは、さらに、ＵＥが到達可能（UE is reachable）となったことをＭＭＥが検知した場合に、ＭＭＥがＳＣＥＦへその旨を通知（NIDD Submit Indication）することを示す。
　上記応答（NIDD Submit Response）を受信したＳＣＥＦは、ＭＭＥからNIDD Submit Indicationが送信されるまでNon-IPデータをバッファする。ＳＣＥＦは、最終的に、ＭＭＥからのNIDD Submit Indicationの受信を契機としてNon-IP data delivery送信リクエストを再送する。
　しかし、ＵＥに到達不能な間に、ＳＣＳ又はＡＳから該当ＵＥに対して２つ以上のNon-IP data delivery送信リクエストがあった場合、次の問題が発生する。
　ＵＥに到達不能であることによって、ＳＣＥＦが第１のNon-IPデータをバッファしている間に、ＳＣＥＦがＳＣＳ又はＡＳから第２のNon-IPデータに関するNon-IP data delivery送信リクエストを受信することがある。この場合、ＳＣＥＦは、第２のNon-IPデータに関するNon-IP data delivery送信リクエストをＭＭＥへ送信する。UEに到達不能の状況であるため、第２のNon-IPデータは、ＵＥに到達せず、第１のNon-IPデータと同様、ＳＣＥＦにバッファされる結果となる。従って、ＵＥに到達不能の状況において、ＳＣＥＦが第２のNon-IPデータに関するNon-IP data delivery送信リクエストを送信することは、ＳＣＥＦとＭＭＥの通信処理をむやみに増加させる悪影響を及ぼす。
　本発明の目的は、Non-IP data deliveryにおいて、ＳＣＥＦとＭＭＥとの間の通信に関する処理負荷が増大することを抑えるＳＣＥＦエンティティ、通信端末、データ処理方法、データ受信方法、及びプログラムを提供することにある。
　本発明の第１の態様にかかるＳＣＥＦエンティティは、通信端末へ配送されなかった第１のNon-IPデータをバッファする記憶部と、サーバ装置から前記通信端末を宛先とする第２のNon-IPデータを受信した際に、前記第１のNon-IPデータがバッファされている場合、前記第２のNon-IPデータを、モバイルネットワーク内の制御装置へ送信することを抑制し、前記第２のNon-IPデータを前記記憶部にバッファする制御部と、を備えるものである。
　本発明の第２の態様にかかる通信端末は、自装置が到達可能になるまでＳＣＥＦエンティティがバッファする複数のNon-IP データを、自装置が到達可能となった際に、制御装置を介して一つのメッセージとして受信する通信部と、前記一つのメッセージに含まれる複数のNon-IP データをそれぞれのNon-IP データ毎に読み取る制御部と、を備えるものである。
　本発明の第３の態様にかかるデータ処理方法は、通信端末へ配送されなかった第１のNon-IPデータをバッファし、サーバ装置から前記通信端末を宛先とする第２のNon-IPデータを受信した際に、前記第１のNon-IPデータがバッファされている場合、前記第２のNon-IPデータをモバイルネットワーク内の制御装置へ送信することを抑制し、前記第２のNon-IPデータをバッファするものである。
　本発明の第４の態様にかかるデータ通信方法は、自装置が到達可能になるまでＳＣＥＦエンティティがバッファする複数のNon-IP データを、自装置が到達可能となった際に、制御装置を介して一つのメッセージとして受信し、前記一つのメッセージに含まれる複数のNon-IP データをそれぞれのNon-IP データ毎に読み取るものである。
　本発明の第５の態様にかかるプログラムは、通信端末へ配送されなかった第１のNon-IPデータをバッファし、サーバ装置から前記通信端末を宛先とする第２のNon-IPデータを受信した際に、前記第１のNon-IPデータがバッファされている場合、前記第２のNon-IPデータをモバイルネットワーク内の制御装置へ送信することを抑制し、前記第２のNon-IPデータをバッファすることをコンピュータに実行させるものである。
　本発明により、Non-IP data deliveryにおいて、ＳＣＥＦとＭＭＥとの間の通信に関する処理負荷が増大することを抑えるＳＣＥＦエンティティ、通信端末、データ処理方法、データ受信方法、及びプログラムを提供することができる。
実施の形態１にかかる通信システムの構成図である。 実施の形態２にかかる通信システムの構成図である。 実施の形態２にかかるＵＥが到達不能である場合の処理の流れを示す図である。 実施の形態２にかかるＵＥが到達可能である場合の処理の流れを示す図である。 実施の形態３にかかるＳＣＥＦが、許容通信量及びレートに関する情報を受信する処理の流れを示す図である。 実施の形態４にかかるＵＥの構成図である。 実施の形態４にかかるＵＥが到達可能である場合の処理の流れを示す図である。 実施の形態５にかかるバッファに格納されたNon-IPデータを示す図である。 実施の形態５にかかるバッファに格納されたNon-IPデータを示す図である。 それぞれの実施の形態にかかるＵＥの構成図である。 それぞれの実施の形態にかかるＳＣＥＦの構成図である。
　（実施の形態１）
　以下、図面を参照して本発明の実施の形態について説明する。図１を用いて本発明の実施の形態１にかかる通信システムの構成例について説明する。図１の通信システムは、ＳＣＥＦ（Service Capability Exposure Function）エンティティ（以下、ＳＣＥＦとする）１０、制御装置２０、サーバ装置３０、及び通信端末４０を有している。ＳＣＥＦ１０、制御装置２０、サーバ装置３０、及び通信端末４０は、プロセッサがメモリに格納されたプログラムを実行することによって動作するコンピュータ装置であってもよい。
　通信端末４０は、携帯電話端末、スマートフォン端末、もしくはタブレット型端末等であってもよい。または、通信端末４０は、Ｍ２Ｍ（Mobile to Mobile）端末、ＭＴＣ（Machine Type Communication）端末、もしくはＩｏＴ（Internet of Things）端末等であってもよい。通信端末４０は、無線アクセスネットワークを介してＳＣＥＦエンティティ１０と通信を行う。
　サーバ装置３０は、例えば、アプリケーションサービスを提供するアプリケーションサーバ（Application Server）であってもよい。もしくは、サーバ装置３０は、アプリケーションサーバとＳＣＥＦ１０との間に配置され、アプリケーションサービスに関するデータを中継するサーバ装置であってもよい。
　制御装置２０は、モバイルネットワーク内に配置されるノード装置である。制御装置２０は、モバイルネットワーク内において制御情報を中継もしくは処理するノード装置である。制御情報は、例えば、C（Control）-Planeデータ、C-Planeメッセージ等と称されてもよい。制御装置２０は、例えば、３ＧＰＰにおいて規定されているＭＭＥもしくはＳＧＳＮ（Serving GPRS（General Packet Radio Service） Support Node）等であってもよい。
　ＳＣＥＦ１０は、３ＧＰＰにおいて動作が規定されているノード装置である。ＳＣＥＦ１０は、３ＧＰＰにおいて規定されているモバイルネットワークであって、モバイル通信事業者が管理するモバイルネットワークと、アプリケーションサーバ等のモバイル通信事業者以外の第３者が管理するサーバ装置等との間に配置される。ＳＣＥＦ１０は、サーバ装置３０に対して、モバイルネットワークにおいて対応可能なサービス、及び当該サービスを提供するための能力に関する情報を、安全に提供する。
　また、ＳＣＥＦ１０は、サーバ装置３０から送信されたNon-IPデータを、モバイルネットワーク内の制御装置２０を介して通信端末４０へ配送もしくは配信（delivery）する。以下の記載において、配送との用語は、配信と置き換えられてもよい。Non-IPデータは、ＩＰプロトコルスタックを使用しないデータである。Non-IP データとは、通信に用いられるデータ・パケットが EPS（Evolved Packet System） の観点からは構造化されていないものを指す。例えば、LoRa, SIGFOX, NB-IoT など 一般に LPWA (Low Power Wide Area) と総称されるテクノロジーは、デバイスの消費電力を低減するため、IP データ・ベアラを確立しない。これらに対応するため、3GPP 網では C-plane で小容量のデータをやりとりする仕組み（Non-IP Data Delivery (NIDD) ）が規定されている。Non-IPデータは、モバイルネットワーク内においては制御情報として伝送される。Non-IPデータは、例えば、ＩｏＴサービスを受けるＩｏＴ端末へ送信されるデータであってもよい。
　続いて、ＳＣＥＦ１０の構成例について説明する。ＳＣＥＦ１０は、記憶部１１及び制御部１２を有している。制御部１２は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、制御部１２は、チップもしくは回路等のハードウェアであってもよい。記憶部１１は、例えば、メモリであってもよい。
　記憶部１１は、通信端末４０へ配送されなかったNon-IPデータをバッファする。言い換えると、記憶部１１は、Non-IPデータを通信端末４０へ再送信するまでに、一時的にNon-IPデータを記憶、保存、もしくは格納する。Non-IPデータが通信端末４０へ配送されない場合とは、例えば、通信端末４０がパワーセーブモードである場合、もしくは、電波状況が悪化し無線通信を行えない場合等がある。Non-IPデータが通信端末４０へ配送されない状態であることを、通信端末４０が到達不能（unreachable）であると言い換えてもよい。また、Non-IPデータが通信端末４０へ配送することができる状態であることを、通信端末４０が到達可能（reachable）であると言い換えてもよい。
　制御部１２は、サーバ装置３０から通信端末４０を宛先とするNon-IPデータを受信した際に、通信端末４０へ配送されなかったNon-IPデータが記憶部１１にバッファされている場合、サーバ装置３０から受信したNon-IPデータをモバイルネットワーク内の制御装置２０へ送信することを抑制し、サーバ装置３０から受信したNon-IPデータを記憶部１１にバッファする。Non-IPデータをモバイルネットワーク内の制御装置２０へ送信することを抑制するとは、Non-IPデータをモバイルネットワーク内の制御装置２０へ送信しないことを含む。
　通信端末４０へ配送されなかったNon-IPデータが記憶部１１にバッファされている場合とは、通信端末４０が到達不能な場合である。そのため、ＳＣＥＦ１０がサーバ装置３０から受信した、通信端末４０を宛先とする新たなNon-IPデータを制御装置２０へ送信しても、制御装置２０は、Non-IPデータを通信端末４０へ送信することができない、もしくは、Non-IPデータを通信端末４０へ送信することができない可能性が高い。
　このような場合に、制御部１２が、サーバ装置３０から受信したNon-IPデータを制御装置２０へ送信せずに、記憶部１１にバッファすることによって、モバイルネットワーク内における不要なトラヒックを発生させることを防止することができる。
　（実施の形態２）
　続いて、図２を用いて本発明の実施の形態２にかかる通信システムの構成例について説明する。図２の通信システムは、ＳＣＥＦ１０、ＭＭＥ２２、ＳＧＳＮ２４、ＲＡＮ（Radio Access Network）２６、ＡＳ３２、ＳＣＳ３４、及びＵＥ４２を有している。
　ＭＭＥ２２及びＳＧＳＮ２４は、図１の制御装置２０に相当する。ＡＳ３２及びＳＣＳ３４は、図２のサーバ装置３０に相当する。ＵＥ４２は、図１の通信端末４０に相当する。ＵＥ４２は、３ＧＰＰにおいて、通信端末の総称として用いられる。
　ＲＡＮ２６は、例えば、ＬＴＥ（Long Term Evolution）通信をサポートするｅＮＢ（evolved Node B）であってもよく、３ＧＰＰにおいていわゆる３Ｇ通信として規定されている無線通信をサポートするＮｏｄｅＢ及びＮｏｄｅＢを制御するＲＮＣ（Radio Network Controller）であってもよい。
　ＭＭＥ２２及びＳＧＳＮ２４は、ＣＰＦ（C-Plane Function）エンティティ（以下、ＣＰＦとする）と称されてもよい。ＭＭＥ２２及びＳＧＳＮ２４は、主に、ＵＥ４２の移動管理、ベアラの設定要求、ベアラの設定指示、ベアラの削除要求、もしくは、ベアラの削除指示を行う装置である。
　ＡＳ３２及びＳＣＳ３４は、ＵＥ４２にアプリケーションサービスを提供するために用いられる装置である。アプリケーションサービスは、例えば、ＩｏＴサービスと言い換えられてもよい。ＡＳ３２又はＳＣＳ３４は、ＳＣＥＦ１０へNon-IPデータを送信する。ＡＳ３２は、ＳＣＳ３４を介さず、ＳＣＥＦ１０へ直接Non-IPデータを送信してもよい。ＡＳ３２又はＳＣＳ３４は、以下の説明において、ＡＳ３２／ＳＣＳ３４、もしくは、ＳＣＳ３４／ＡＳ３２と記載されることがある。
　ＳＣＥＦ１０は、ＳＣＳ３４／ＡＳ３２から送信されたNon-IPデータをＭＭＥ２２又はＳＧＳＮ２４へ送信する。ＭＭＥ２２又はＳＧＳＮ２４は、ＲＡＮ２６を介してNon-IPデータをＵＥ４２へ配送する。ＭＭＥ２２又はＳＧＳＮ２４は、ＵＥ４２が到達不能である場合、Non-IPデータをＳＣＥＦ１０へ返送する。ＳＣＥＦ１０は、ＵＥ４２へ配送されなかったNon-IPデータをバッファする。
　また、図２は、ＳＣＥＦ１０、ＭＭＥ２２、ＲＡＮ２６、及びＳＧＳＮ２４がＨＰＬＭＮ（Home Public Land Mobile Network）に属している構成を示している。一方、ＳＣＥＦ１０がＨＰＬＭＮに属し、ＭＭＥ２２、ＳＧＳＮ２４、及びＲＡＮ２６がＶＰＬＭＮ（Visited PLMN）に属する場合、ＳＣＥＦ１０とＭＭＥ２２との間、さらに、ＳＣＥＦ１０とＳＧＳＮ２４との間に、ＩＷＫ（Interworking）－ＳＣＥＦが配置されてもよい。ＩＷＫ－ＳＣＥＦは、ＶＰＬＭＮに配置され、ＳＣＥＦ１０とＭＭＥ２２との間の通信、さらに、ＳＣＥＦ１０とＳＧＳＮ２４との間の通信を中継する。
　続いて、図３を用いて、ＵＥ４２が到達不能である場合の処理の流れについて説明する。図３においては、ＳＣＥＦ１０は、ＭＭＥ２２を介してNon-IPデータを配送する処理について説明しているが、ＭＭＥ２２の代わりにＳＧＳＮ２４が用いられてもよい。
　はじめに、ＳＣＳ３４／ＡＳ３２は、NIDD Submit RequestメッセージをＳＣＥＦ１０へ送信する（Ｓ１１）。NIDD Submit Requestメッセージは、External Identifier又はMSISDN（Mobile Subscriber Integrated Service Digital Network Number）を含む。さらに、NIDD Submit Requestメッセージは、SCS/AS Reference ID、及びNon-IPデータを含む。External Identifier及びMSISDNは、ＵＥ４２の識別情報である。SCS/AS Reference IDは、ＳＣＳ３４又はＡＳ３２の識別情報である。
　次に、ＳＣＥＦ１０は、ＳＣＳ３４／ＡＳ３２からNIDD Submit Requestメッセージを受信すると、External Identifier又はMSISDNに関連付けられたSCEF EPS bearer contextが存在するか確認する（Ｓ１２）。さらに、ＳＣＥＦ１０は、ＳＣＳ３４／ＡＳ３２からNIDD Submit Requestメッセージを受信すると、ＳＣＳ３４／ＡＳ３２がNIDD Submit Requestメッセージを送信することを認可されているか確認する（Ｓ１２）。さらに、ＳＣＥＦ１０は、ＳＣＳ３４／ＡＳ３２からNIDD Submit Requestメッセージを受信すると、ＳＣＳ３４／ＡＳ３２に許容されているNon-IPデータの許容通信量及びレートの少なくとも一方を超過していないかを確認する（Ｓ１２）。許容通信量は、例えば、１日あたりに送信されたデータ量の累積値であってもよい。
　SCEF EPS bearer contextは、ＭＭＥ２２とＳＣＥＦ１０との間においてNon-IPデータを送信するためのベアラが確立されていることを示す情報である。ＭＭＥ２２とＳＣＥＦ１０との間には、３ＧＰＰにおいてリファレンスポイントとしてT6aが定められている。ＭＭＥ２２とＳＣＥＦ１０との間のベアラは、ＵＥ４２のAttach処理時に確立される。また、ＭＭＥ２２の代わりにＳＧＳＮ２４が用いられることがある。ＳＧＳＮ２４とＳＣＥＦ１０との間には、３ＧＰＰにおいてリファレンスポイントとしてT6bが定められている。ＵＥ４２のSCEF EPS bearerは、ＵＥ４２とＳＣＳ３４／ＡＳ３２との間でNon-IPデータを伝送するための、ＳＣＥＦ１０とＭＭＥ２２との間に設定されるベアラである。
　ＳＣＥＦ１０は、SCEF EPS bearer contextが存在しない、ＳＣＳ３４／ＡＳ３２がNIDD Submit Requestメッセージを送信することを認可されていない、及び、ＳＣＳ３４／ＡＳ３２に許容されているNon-IPデータの許容通信量及びレートの少なくとも一方を超過している、との事象の少なくとも１つの事象に該当する場合、ＳＣＳ３４／ＡＳ３２へNIDD Submit Responseメッセージを送信する（Ｓ１３）。NIDD Submit Responseメッセージには、NIDD Submit Responseメッセージが送信される要因となった情報が設定されている。NIDD Submit Responseメッセージが送信される要因となった情報は、例えば、NIDD Submit Responseメッセージに設定されるcause valueを用いて示されてもよい。
　ＳＣＥＦ１０は、ＳＣＳ３４／ＡＳ３２に許容されているNon-IPデータの許容通信量及びレートの少なくとも一方を超過している場合、ステップＳ１１において受信したNon-IP データを廃棄してもよい。
　また、ＳＣＥＦ１０は、ＳＣＳ３４／ＡＳ３２に許容されているNon-IPデータの許容通信量を超過している場合、超過分のNon-IPデータを廃棄してもよい。また、ＳＣＥＦ１０は、ＳＣＳ３４／ＡＳ３２に許容されているNon-IPデータのレートを超過している場合、一部のNon-IPデータを廃棄し、許容されているレートになるように制御してもよい。
　また、ＳＣＥＦ１０は、External Identifier又はMSISDNに関連付けられたSCEF EPS bearer contextが存在しない場合、External Identifier又はMSISDNに該当するＵＥを管理するＭＭＥとの間において、Non-IP PDN connectionを確立するための処理を実行してもよい。
　次に、ＳＣＥＦ１０は、SCEF EPS bearer contextが存在し、ＳＣＳ３４／ＡＳ３２がNIDD Submit Requestメッセージを送信することを認可されており、さらに、ＳＣＳ３４／ＡＳ３２に許容されているNon-IPデータの許容通信量及びレートを超過していない場合、ＳＣＥＦ１０の制御部１２は、ＵＥ４２のSCEF EPS bearerへ送信するための別のNon-IPデータを記憶部１１に既にバッファしているか否かを判定する（Ｓ１４）。ＵＥ４２のSCEF EPS bearerへ送信するための別のNon-IPデータは、例えば、ＵＥ４２へ配送されなかったNon-IPデータであってもよい。
　ＳＣＥＦ１０の制御部１２は、ＵＥ４２のSCEF EPS bearerへ送信するための別のNon-IPデータを記憶部１１にバッファしていないと判定した場合、ＳＣＥＦ１０は、NIDD Submit RequestメッセージをＭＭＥ２２へ送信する（Ｓ１５）。NIDD Submit Requestメッセージは、User Identity、EPS（Evolved Packet System） Bearer ID、SCEF ID、Non-IPデータ、SCEF Wait Time、及びMaximum Re-transmission timeを含む。User Identityは、ＵＥ４２の識別情報である。EPS bearer IDは、ＳＣＥＦ１０とＭＭＥ２２との間に設定されたベアラ（SCEF EPS bearer）の識別情報である。SCEF IDは、ＳＥＣＦ１０の識別情報である。SCEF Wait Timeは、ＳＣＥＦ１０が、ＭＭＥ２２から送信されるResponseメッセージを待つことができる時間である。Maximum Re-transmission timeは、ＳＣＥＦ１０がメッセージを再送信することができる時間である。
　次に、ＭＭＥ２２は、NIDD Submit Requestメッセージを受信すると、ＵＥ４２が到達不能であることを検出する（Ｓ１６）。次に、ＭＭＥ２２は、NIDD Submit ResponseメッセージをＳＣＥＦへ送信する（Ｓ１７）。NIDD Submit Responseメッセージは、Cause及びRequested Re-transmission Timeを含む。Causeは、ＵＥ４２がパワーセービングモードであるため一時的に到達可能ではないとしてNon-IPデータがＵＥ４２へ配送されなかったこと、さらに、ＵＥが到達可能（UE is reachable）となったことをＭＭＥ２２が検知した場合に、ＭＭＥ２２がＳＣＥＦ１０へその旨を通知（NIDD Submit Indication）することを示す内容が設定される。
　Requested Re-transmission Timeには、ＳＣＥＦ１０が現在到達不能であるＵＥ４２へダウンリンクデータを再送信することが可能となることが予測される時間を示す。
　また、ＭＭＥ２２は、ＵＥが到達可能（UE is reachable）となったことをＭＭＥ２２が検知した場合に、ＳＣＥＦ１０へその旨を通知することを示すNot Reachable for NIDD flagを設定する。
　次に、ＳＣＥＦ１０は、ＭＭＥ２２からNIDD Submit Responseメッセージを受信すると、ＵＥ４２がパワーセービングモードであるため一時的に到達可能ではないことを示すCause valueを参照して、ＵＥ４２が到達不能であることを理解する。さらに、ＳＣＥＦ１０は、ステップＳ１５において送信を試みたNon-IPデータをバッファする（Ｓ１８）。また、ＳＣＥＦ１０は、ステップＳ１４において、ＵＥ４２のSCEF EPS bearerへ送信するための別のNon-IPデータを記憶部１１に既にバッファしていると判定した場合、ステップＳ１５～Ｓ１７の処理を実行することなく、ステップＳ１１において受信したNon-IPデータをバッファする（Ｓ１８）。
　次に、ＳＣＥＦ１０は、ＭＭＥ２２から受信した結果を含む、NIDD Submit ResponseメッセージをＳＣＳ３４／ＡＳ３２へ送信する（Ｓ１９）。もしくは、NIDD Submit Responseメッセージは、ＳＣＥＦ１０が、ステップＳ１１において受信したNon-IPデータをＭＭＥ２２へ送信することなくバッファしたことを示す情報を含んでもよいし、ＵＥ４２がパワーセービングモードであるため一時的に到達可能ではないことを示す情報を含んでもよい。
　続いて、図４を用いて、ＵＥ４２が到達可能である場合の処理の流れについて説明する。はじめに、ＭＭＥ２２は、ＵＥ４２が到達可能もしく到達可能になるところであることを検出する（Ｓ２１）。例えば、ＭＭＥ２２は、ＵＥ４２がＴＡＵ（Tracking Area Update）を実行することによってパワーセービングモードから復帰した場合、もしくは、Mobile Originated通信が開始された場合等に、ＵＥ４２が到達可能であることを検出する。
　次に、ＭＭＥ２２は、図３のステップＳ１７においてNIDD Submit Responseメッセージを送信したＳＣＥＦ１０に対して、NIDD Submit Indicationメッセージを送信する（Ｓ２２）。NIDD Submit Indicationメッセージは、User Identityを含む。User Identityは、ＵＥ４２の識別情報である。
　次に、ＳＣＥＦ１０は、ＭＭＥ２２からNIDD Submit Indicationメッセージを受信すると、バッファした順に、バッファしていたNon-IPデータをNIDD Submit Requestメッセージを用いてＭＭＥ２２へ送信する（Ｓ２３）。例えば、ＳＣＥＦ１０は、図３のステップＳ１４において、ＵＥ４２のSCEF EPS bearerへ送信するための別のNon-IPデータを記憶部１１に既にバッファしていると判定した場合、はじめに、既にバッファされていたNon-IPデータをＭＭＥ２２へ送信する。その後、ＳＣＥＦ１０は、図３のステップＳ１１において受信したNon-IPデータをＭＭＥ２２へ送信する。
　また、ＳＣＥＦ１０は、Non-IPデータをＭＭＥ２２へ向けて、ＵＥ４２のSCEF EPS bearerへ送信する際に、ＳＣＳ３４／ＡＳ３２に許容されているNon-IPデータの許容通信量及びレートを超過しないように通信量及びレート制御を適用する。つまり、ＳＣＥＦ１０は、図３のステップＳ１５においてＭＭＥ２２へNon-IPデータを送信する場合に加えて、図４のステップＳ２３においてNon-IPデータを送信する場合においても、通信量及びレート制御を適用する。
　次に、ＭＭＥ２２は、NIDD Submit Requestメッセージを受信すると、ＵＥ４２へNon-IPデータを配送する（Ｓ２４）。例えば、ＵＥ４２とＭＭＥ２２との間においてC-Plane接続を確立中であれば、ＭＭＥ２２は、ＵＥ４２へNon-IPデータを即時送信する。ＵＥ４２とＭＭＥ２２との間においてC-Plane接続を確立中でなければ、ＵＥ４２を呼び出すページング処理を行う。ＭＭＥ２２は、ページング処理を行うことによってＵＥ４２との間においてC-Plane接続を確立すると、ＵＥ４２へNon-IPデータを送信する。
　次に、ＭＭＥ２２は、ステップＳ２４におけるNon-IPデータの配送を開始することができた場合、ＳＣＥＦ１０へNIDD Submit Responseメッセージを送信する（Ｓ２５）。NIDD Submit Responseメッセージは、Non-IPデータの配送を開始することができたことを示すcause valueを含む。さらに、ＳＣＥＦ１０は、ＭＭＥ２２から受信したNIDD Submit Responseメッセージを、ＳＣＳ３４／ＡＳ３２へ送信する（Ｓ２６）。
　また、ステップＳ２３～Ｓ２６の動作は、バッファされているNon-IPデータの数に応じて繰り返し実施される。つまり、ＳＣＥＦ１０は、バッファされているNon-IPデータ毎に、NIDD Submit RequestメッセージをＭＭＥ２２へ送信する。
　また、ステップＳ２３において、ＳＣＥＦ１０は、Non-IPデータをＭＭＥ２２へ送信する際に、ＳＣＳ３４／ＡＳ３２に許容されているNon-IPデータの許容通信量及びレートの代わりに、ＳＣＥＦ１０に許容されているNon-IPデータの許容量及びレートを超過しないように通信量及びレート制御をしてもよい。
　以上説明したように、本発明の実施の形態２にかかるＳＣＥＦ１０は、ＵＥ４２へ送信すべきNon-IPデータがバッファされているか否かを判定することができる。さらに、ＳＣＥＦ１０は、ＵＥ４２へ送信すべきNon-IPデータがバッファされていると判定した場合、NIDD Submit Requestメッセージの送信処理及びNIDD Submit Responseメッセージの受信処理を行うことなく、Non-IPデータをバッファすることができる。これにより、ＳＣＥＦ１０とＭＭＥ２２との間において不要なトラヒックが発生することを回避することができる。
　さらに、ＳＣＥＦ１０は、バッファしていたNon-IPデータをＭＭＥ２２へ向けて、ＵＥ４２のSCEF EPS bearerへ送信する場合に、先にバッファしたNon-IPデータをＭＭＥ２２へ向けて、ＵＥ４２のSCEF EPS bearerへ送信することができる。これより、ＵＥ４２において、Non-IPデータを受信する順序が逆転することを回避することができる。その結果、Non-IPデータの順序性を維持することが要求されるアプリケーションサービスを提供することができる。
　さらに、ＳＣＥＦ１０は、バッファしていたNon-IPデータをＭＭＥ２２へ向けて、ＵＥ４２のSCEF EPS bearerへ送信する場合に、ＳＣＳ３４／ＡＳ３２もしくはＳＣＥＦ１０に許容されているNon-IPデータの許容通信量及びレートを超過しないように通信量及びレート制御を適用することができる。これより、ＳＣＥＦ１０がNon-IPデータを再送する際にバースト転送が発生することを回避することができる。その結果、通信速度の面において低性能のＩｏＴデバイス等のＵＥ４２が、Non-IPデータの受信に失敗する事象を減少もしくは回避させることができる。
　（実施の形態３）
　続いて、図５を用いて本発明の実施の形態３にかかるＳＣＥＦ１０が、許容通信量及びレートに関する情報を受信する処理の流れについて説明する。実施の形態２においては、ＳＣＥＦ１０は、ＳＣＳ３４／ＡＳ３２に許容されているNon-IPデータの許容通信量及びレートを超過しないように通信量及びレート制御を適用している。これに対して、実施の形態３においては、ＵＥ４２に、又はＵＥ４２のSCEF EPS bearerに許容されているNon-IPデータの許容通信量及びレートを超過しないように通信量及びレート制御を適用する。ＵＥ４２のSCEF EPS bearerは、ＵＥ４２とＳＣＳ３４／ＡＳ３２との間でNon-IPデータを伝送するための、ＳＣＥＦ１０とＭＭＥ２２との間に設定されるベアラである。
　はじめに、ＳＣＳ３４／ＡＳ３２は、NIDD Configuration RequestメッセージをＳＣＥＦ１０へ送信する（Ｓ３１）。NIDD Configuration Requestメッセージは、External IdentifierもしくはMSISDNを含む。External IdentifierもしくはMSISDNは、ＵＥ４２を識別する情報である。さらに、NIDD Configuration Requestメッセージは、SCS/AS Reference IDを含む。次に、ＳＣＥＦ１０は、NIDD Configuration Requestメッセージに含まれるExternal IdentifierもしくはMSISDN、さらに、SCS/AS Reference IDを記憶部１１に格納する（Ｓ３２）。
　次に、ＳＣＥＦ１０は、ＳＣＳ３４／ＡＳ３２が、受信したExternal IdentifierもしくはMSISDNに関するNIDD Configuration Requestメッセージを送信することを認可されているかを確認するために、ＨＳＳ（Home Subscriber Server）へNIDD Authorization Requestメッセージを送信する（Ｓ３３）。NIDD Authorization Requestメッセージは、External IdentifierもしくはMSISDN、さらに、ＳＣＥＦ１０に関連付けられたＡＰＮ（Access Point Name）を含む。ＨＳＳは、複数のＵＥに関する加入者情報を管理するノード装置である。
　次に、ＨＳＳは、ＳＣＳ３４／ＭＭＥ２２が、NIDD Configuration Requestメッセージを送信することが認可されていると判定する（Ｓ３４）。さらに、ＨＳＳは、NIDD Authorization Requestメッセージに含まれるExternal IdentifierもしくはMSISDNに対応付けられたＩＭＳＩ（International Mobile Subscriber Identity）を抽出する。ＩＭＳＩは、モバイルネットワーク内におけるＵＥの識別情報として用いられる。
　次に、ＨＳＳは、NIDD Authorization Requestメッセージに対する応答としてNIDD Authorization ResponseメッセージをＳＣＥＦ１０へ送信する（Ｓ３５）。NIDD Authorization Responseメッセージは、External IdentifierもしくはMSISDNに対応付けられたＩＭＳＩを含む。さらに、NIDD Authorization Responseメッセージは、ＵＥ４２に許容されているNon-IPデータの許容通信量及びレートの少なくとも一方を示すLoadControlInformationを含む。ＨＳＳは、ＵＥ毎に、又はＵＥのSCEF EPS bearer毎に許容されているNon-IPデータの許容通信量及びレートの少なくとも一方を加入者情報として管理しているとする。
　次に、ＳＣＥＦ１０は、NIDD Configuration Requestメッセージに対する応答として、NIDD Configuration ResponseメッセージをＳＣＳ３４／ＡＳ３２へ送信する（Ｓ３６）。
　図５の処理が実行されることによって、ＳＣＥＦ１０は、ＵＥ４２に許容されているNon-IPデータの許容通信量及びレートの少なくとも一方を示す情報をＨＳＳから取得することができる。または、ＳＣＥＦ１０は、ＵＥ４２のSCEF EPS bearerに許容されているNon-IPデータの許容通信量及びレートの少なくとも一方を示す情報をＨＳＳから取得することができる。
　また、ＳＣＥＦ１０は、図４と同じシーケンスに従ってＵＥ４２へNon-IPデータを送信することができる。ただし、ＳＣＥＦ１０は、図３のステップＳ１５、および、図４のステップＳ２３において、Non-IPデータをＭＭＥ２２へ向けて、ＵＥ４２のSCEF EPS bearerへ送信する際に、ＵＥ４２又はＵＥ４２のSCEF EPS bearerに許容されているNon-IPデータの許容通信量及びレートを超過しないように通信量及びレート制御を適用する。
　以上説明したように、ＳＣＥＦ１０は、バッファしていたNon-IPデータをＭＭＥ２２へ向けて、ＵＥ４２のSCEF EPS bearerへ送信する場合に、ＵＥ４２に、又はＵＥ４２のSCEF EPS bearerに許容されているNon-IPデータの許容通信量及びレートを超過しないように通信量及びレート制御を適用することができる。これより、通信速度の面において低性能のＩｏＴデバイス等のＵＥ４２が、Non-IPデータの受信に失敗する事象を減少もしくは回避させることができる。
　（実施の形態４）
　続いて、図６を用いて本発明の実施の形態４にかかるＵＥ４２の構成例について説明する。ＵＥ４２は、通信部４３及び制御部４４を有している。通信部４３及び制御部４４は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、通信部４３及び制御部４４は、チップもしくは回路等のハードウェアであってもよい。
　通信部４３は、ＭＭＥ２２から配送されるNon-IPデータを受信する。ここで、通信部４３は、複数のNon-IPデータを一つのメッセージを用いて受信する。つまり、ＭＭＥ２２は、ＳＣＥＦ１０にバッファされているNon-IPデータの数と同じ回数、Non-IPデータの送信を繰り返すのではなく、複数のNon-IPデータを含む一つのメッセージをＵＥ４２へ送信する。通信部４３は、複数のNon-IPデータを含む１つのメッセージを制御部４４へ出力する。
　制御部４４は、一つのメッセージに含まれる複数のNon-IPデータを、それぞれのNon-IPデータ毎に読み取る。言い換えると、制御部４４は、一つのメッセージに含まれる複数のNon-IPデータを、それぞれのNon-IPデータ毎に切り分けて読み取る。さらに言い換えると、制御部４４は、一つのメッセージに含まれる複数のNon-IPデータをパース（parse）して読み取る。
　制御部４４は、例えば、Non-IPデータのデータサイズに関する情報を保持していてもよい。例えば、複数のNon-IPデータを含む一つのメッセージ内に、それぞれのNon-IPデータのデータサイズに関する情報が設定されていてもよい。もしくは、Non-IPデータのデータサイズがモバイルネットワーク内において予め定められている場合、制御部４４は、予め定められているNon-IPデータのデータサイズに関する情報を保持していてもよい。制御部４４は、Non-IPデータのデータサイズに従って、一つのメッセージに含まれる複数のNon-IPデータを読み取ってもよい。
　続いて、図７を用いて、ＵＥ４２が到達可能である場合の処理の流れについて説明する。図７のステップＳ４１及びＳ４２は、図４のステップＳ２１及びＳ２２と同様であるため詳細な説明を省略する。
　次に、ＳＣＥＦ１０は、ＭＭＥ２２からNIDD Submit Indicationメッセージを受信すると、バッファされている複数のNon-IPデータを一つのNIDD Submit Requestメッセージを用いてＭＭＥ２２へ向けて、ＵＥ４２のSCEF EPS bearerへ送信する（Ｓ４３）。例えば、ＳＣＥＦ１０は、NIDD Submit Requestメッセージの先頭に近いデータ領域に、はじめにバッファしていたNon-IPデータを設定し、メッセージの最後尾に近いデータ領域に、新たにバッファされたNon-IPデータを設定してもよい。
　次に、ＭＭＥ２２は、複数のNon-IPデータを含むNIDD Submit Requestメッセージを受信すると、ＵＥ４２へ一つのメッセージを用いて複数のNon-IPデータを配送する（Ｓ４４）。
　次に、ＭＭＥ２２は、ステップＳ４４におけるNon-IPデータの配送を開始することができた場合、ＳＣＥＦ１０へNIDD Submit Responseメッセージを送信する（Ｓ４５）。次に、ＳＣＥＦ１０は、Non-IPデータ毎に、NIDD Submit Responseメッセージを、ＳＣＳ３４／ＡＳ３２へ送信する（Ｓ４６及びＳ４７）。例えば、ステップＳ４３において、ＳＣＥＦ１０は、最初にバッファしていたNon-IPデータ#1と、後からバッファしたNon-IPデータ#2とを一つのNIDD Submit Requestメッセージを用いてＭＭＥ２２へ送信したとする。この場合、ＳＣＥＦ１０は、NIDD Submit Responseメッセージを受信すると、Non-IPデータ#1をＵＥ４２へ配送したことを示すNIDD Submit ResponseメッセージをステップＳ４６において送信し、Non-IPデータ#2をＵＥ４２へ配送したことを示すNIDD Submit ResponseメッセージをステップＳ４７において送信する。
　以上説明したように、図７に示す処理を実行することによって、ＳＣＥＦ１０は、一つのNIDD Submit Requestメッセージを用いて複数のNon-IPデータをＭＭＥ２２へ向けて、ＵＥ４２のSCEF EPS bearerへ配送することができる。さらに、ＭＭＥ２２は、一つのメッセージを用いて複数のNon-IPデータをＵＥ４２へ配送することができる。さらに、ＵＥ４２は、一つのメッセージに含まれる複数のNon-IPデータを、Non-IPデータ毎に読み取ることができる。
　その結果、モバイルネットワーク内において伝送されるメッセージ数を削減することができるため、モバイルネットワーク内に発生し得る輻輳を回避することができる。例えば、ＵＥ４２としてＩｏＴ端末が用いられた場合、モバイルネットワークにかなり多くの数のＩｏＴ端末が接続されることが想定される。そのため、ＵＥ４２としてＩｏＴ端末が用いられた場合等に、メッセージ数を削減するより多くの効果を得ることができる。
　（実施の形態５）
　続いて、実施の形態５にかかるNon-IPデータのバッファへの格納処理について説明する。アプリケーションによっては、複数のNon-IPデータをバッファへ格納する際に、既にバッファに存在するNon-IPデータは不要であり、新しくバッファへ格納されるNon-IPデータのみが必要である場合がある。
　例えば、Non-IPデータがＵＥ４２の状態を示す情報である場合、新しいNon-IPデータのみが必要となってもよい。具体的には、ＵＥ４２がランプである場合に、Non-IPデータは、ランプ状態をONにするかOFFにするかを示す情報を含んでもよい。はじめにランプ状態をONにすることを示すNon-IPデータがバッファに格納された後に、ランプの状態をOFFにすることを示すNon-IPデータがＳＣＳ３４／ＡＳ３２からＳＣＥＦ１０へ送信されてきた場合、はじめにバッファに格納されたNon-IPデータは不要となる。
　このような場合、ＳＣＥＦ１０は、最初にバッファに格納したNon-IPデータを削除し、後からＳＣＳ３４／ＡＳ３２からＳＣＥＦ１０へ送信されてきたNon-IPデータのみをバッファするようにしてもよい。
　ここで、図８及び図９を用いて、バッファに格納されたNon-IPデータについて説明する。図８は、図３のステップＳ１１が送信される前にバッファされているNon-IPデータを示している。図９は、図３のステップＳ１８においてバッファされたNon-IPデータを示している。
　図８及び図９のバッファ順は、１番が最も早くバッファされたNon-IPデータであり、３番が最も遅くバッファされたNon-IPデータであることを示している。Non-IPデータの設定内容は、例えば、ＵＥ４２の制御内容が示されてもよい。例えば、図８のバッファ順が２であるNon-IPデータは、機器のスイッチをONにすることを示す。さらに、それぞれのNon-IPデータには属性ＩＤが設定されているとする。例えば、バッファ順が２であるNon-IPデータは、属性ＩＤとしてランプ状態を示す情報が設定されている。
　ここで、ＳＣＥＦ１０は、属性ＩＤが同じNon-IPデータを受信した場合、既にバッファされているNon-IPデータを削除してもよい。図９は、バッファ順が２であるNon-IPデータと、新たに受信したNon-IPデータの属性ＩＤが、ランプ状態で一致している場合に、既にバッファされているNon-IPデータを削除していることを示している。
　以上説明したように、ＳＣＥＦ１０は、Non-IPデータをバッファする際に、既にバッファされているNon-IPデータであって、不要なNon-IPデータを削除することができる。これにより、ＳＣＥＦ１０のバッファサイズを縮小させることができる。
　続いて以下では、上述の複数の実施形態で説明されたＵＥ４２及びＳＣＥＦ１０の構成例について説明する。
　図１０は、ＵＥ４２の構成例を示すブロック図である。Radio Frequency（RF）トランシーバ１１０１は、ＲＡＮ２６と通信するためにアナログRF信号処理を行う。RFトランシーバ１１０１により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ１１０１は、アンテナ１１０２及びベースバンドプロセッサ１１０３と結合される。すなわち、RFトランシーバ１１０１は、変調シンボルデータ（又はOFDMシンボルデータ）をベースバンドプロセッサ１１０３から受信し、送信RF信号を生成し、送信RF信号をアンテナ１１０２に供給する。また、RFトランシーバ１１０１は、アンテナ１１０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ１１０３に供給する。
　ベースバンドプロセッサ１１０３は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮／復元、(b) データのセグメンテーション／コンカテネーション、(c) 伝送フォーマット（伝送フレーム）の生成／分解、(d) 伝送路符号化／復号化、(e) 変調（シンボルマッピング）／復調、及び(f) Inverse Fast Fourier Transform（IFFT）によるOFDMシンボルデータ（ベースバンドOFDM信号）の生成などを含む。一方、コントロールプレーン処理は、レイヤ１（e.g., 送信電力制御）、レイヤ２（e.g., 無線リソース管理、及びhybrid automatic repeat request（HARQ）処理）、及びレイヤ３（e.g., アタッチ、モビリティ、及び通話管理に関するシグナリング）の通信管理を含む。
　例えば、LTEおよびLTE-Advancedの場合、ベースバンドプロセッサ１１０３によるデジタルベースバンド信号処理は、Packet Data Convergence Protocol（PDCP）レイヤ、Radio Link Control（RLC）レイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、ベースバンドプロセッサ１１０３によるコントロールプレーン処理は、Non-Access Stratum（NAS）プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。
　ベースバンドプロセッサ１１０３は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., Digital Signal Processor（DSP））とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., Central Processing Unit（CPU）、又はMicro Processing Unit（MPU））を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ１１０４と共通化されてもよい。
　アプリケーションプロセッサ１１０４は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ１１０４は、複数のプロセッサ（複数のプロセッサコア）を含んでもよい。アプリケーションプロセッサ１１０４は、メモリ１１０６又は図示されていないメモリから読み出されたシステムソフトウェアプログラム（Operating System（OS））及び様々なアプリケーションプログラム（例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーション）を実行することによって、ＵＥ４２の各種機能を実現する。
　いくつかの実装において、図１０に破線（１１０５）で示されているように、ベースバンドプロセッサ１１０３及びアプリケーションプロセッサ１１０４は、１つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ１１０３及びアプリケーションプロセッサ１１０４は、１つのSystem on Chip（SoC）デバイス１１０５として実装されてもよい。SoCデバイスは、システムLarge Scale Integration（LSI）またはチップセットと呼ばれることもある。
　メモリ１１０６は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ１１０６は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory（MROM）、Electrically Erasable Programmable ROM（EEPROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリ１１０６は、ベースバンドプロセッサ１１０３、アプリケーションプロセッサ１１０４、及びSoC１１０５からアクセス可能な外部メモリデバイスを含んでもよい。メモリ１１０６は、ベースバンドプロセッサ１１０３内、アプリケーションプロセッサ１１０４内、又はSoC１１０５内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ１１０６は、Universal Integrated Circuit Card（UICC）内のメモリを含んでもよい。
　メモリ１１０６は、上述の複数の実施形態で説明されたＵＥ４２による処理を行うための命令群およびデータを含むソフトウェアモジュール（コンピュータプログラム）を格納してもよい。いくつかの実装において、ベースバンドプロセッサ１１０３又はアプリケーションプロセッサ１１０４は、当該ソフトウェアモジュールをメモリ１１０６から読み出して実行することで、上述の実施形態で説明されたＵＥ４２の処理を行うよう構成されてもよい。
　図１１は、ＳＣＥＦ１０の構成例を示すブロック図である。図１１を参照すると、ＳＣＥＦ１０は、ネットワークインターフェース１２０１、プロセッサ１２０２、及びメモリ１２０３を含む。ネットワークインターフェース１２０１は、ネットワークノード（e.g., ＭＭＥ２２もしくはＳＧＳＮ２４）と通信するために使用される。ネットワークインターフェース１２０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード（NIC）を含んでもよい。
　プロセッサ１２０２は、メモリ１２０３からソフトウェア（コンピュータプログラム）を読み出して実行することで、上述の実施形態においてシーケンス図及びフローチャートを用いて説明されたＳＣＥＦ１０の処理を行う。プロセッサ１２０２は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ１２０２は、複数のプロセッサを含んでもよい。
　メモリ１２０３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ１２０３は、プロセッサ１２０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１２０２は、図示されていないI/Oインタフェースを介してメモリ１２０３にアクセスしてもよい。
　図１１の例では、メモリ１２０３は、ソフトウェアモジュール群を格納するために使用される。プロセッサ１２０２は、これらのソフトウェアモジュール群をメモリ１２０３から読み出して実行することで、上述の実施形態において説明されたＳＣＥＦ１０の処理を行うことができる。
　図１０及び図１１を用いて説明したように、上述の実施形態にＵＥ４２及びＳＣＥＦ１０が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（Non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、Compact Disc Read Only Memory（CD-ROM）、CD-R、CD-R/W、半導体メモリ（例えば、マスクROM、Programmable ROM（PROM）、Erasable PROM（EPROM）、フラッシュROM、Random Access Memory（RAM））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
　なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、本発明は、それぞれの実施の形態を適宜組み合わせて実施されてもよい。
　以上、実施の形態を参照して本願発明を説明したが、本願発明は上記によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
　この出願は、２０１６年１０月７日に出願された日本出願特願２０１６－１９９０９３を基礎とする優先権を主張し、その開示の全てをここに取り込む。
　上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
　（付記１）
　通信端末へ配送されなかった第１のNon-IPデータをバッファする記憶部と、
　サーバ装置から前記通信端末を宛先とする第２のNon-IPデータを受信した際に、前記第１のNon-IPデータがバッファされている場合、前記第２のNon-IPデータをモバイルネットワーク内の制御装置へ送信することを抑制し、前記第２のNon-IPデータを前記記憶部にバッファする制御部と、を備えるＳＣＥＦエンティティ。
　（付記２）
　前記制御部は、
　前記サーバ装置から前記第２のNon-IPデータを受信した際に、前記第１のNon-IPデータがバッファされているか否かを判定し、前記第１のNon-IPデータがバッファされていると判定した場合、前記第２のNon-IPデータを前記記憶部にバッファし、前記第１のNon-IPデータがバッファされていないと判定した場合、前記制御装置へ前記第２のNon-IPデータを送信する、付記１に記載のＳＣＥＦエンティティ。
　（付記３）
　前記制御部は、
　前記制御装置から、前記通信端末へNon-IPデータを配送可能な状態であることを示すメッセージを受信すると、前記記憶部にバッファされている前記第１及び第２のNon-IPデータを前記制御装置へ送信する、付記１又は２に記載のＳＣＥＦエンティティ。
　（付記４）
　前記制御部は、
　前記記憶部にバッファされた順に、前記記憶部にバッファされているNon-IPデータを、前記制御装置へ送信する、付記３に記載のＳＣＥＦエンティティ。
　（付記５）
　前記制御部は、
　前記記憶部にバッファされている複数のNon-IPデータを含む１つのメッセージを前記制御装置へ送信する、付記３又は４に記載のＳＣＥＦエンティティ。
　（付記６）
　前記制御部は、
　前記サーバ装置に許容されている通信量もしくは通信レートを満たすように前記第１及び第２のNon-IPデータを前記制御装置へ送信する、付記３乃至５のいずれか１項に記載のＳＣＥＦエンティティ。
　（付記７）
　前記制御部は、
　前記サーバ装置から前記通信端末を宛先とする前記第２のNon-IPデータを受信した際に、前記サーバ装置に許容されている通信量もしくは通信レートを超過している場合、前記第２のNon-IPデータを廃棄する、付記１乃至６のいずれか１項に記載のＳＣＥＦエンティティ。
　（付記８）
　前記制御部は、
　前記通信端末または前記通信端末がNon-IPデータを伝送する通信ベアラに許容されている通信量もしくは通信レートを満たすように前記第１及び第２のNon-IPデータを前記制御装置へ送信する、付記３乃至５のいずれか１項に記載のＳＣＥＦエンティティ。
　（付記９）
　前記制御部は、
　前記サーバ装置から前記通信端末を宛先とする前記第２のNon-IPデータを受信した際に、前記通信端末または前記通信端末がNon-IPデータを伝送する通信ベアラに許容されている通信量もしくは通信レートを超過している場合、前記第２のNon-IPデータを廃棄する、付記１乃至８のいずれか１項に記載のＳＣＥＦエンティティ。
　（付記１０）
　前記制御部は、
　前記通信端末または前記通信端末がNon-IPデータを伝送する前記通信ベアラに許容されている通信量もしくは通信レートに関する情報を、前記モバイルネットワーク内に配置されている加入者情報管理装置から受信する、付記８又は９に記載のＳＣＥＦエンティティ。
　（付記１１）
　前記制御部は、
　前記ＳＣＥＦエンティティに許容されている通信量もしくは通信レートを満たすように前記第１及び第２のNon-IPデータを前記制御装置へ送信する、付記３乃至５のいずれか１項に記載のＳＣＥＦエンティティ。
　（付記１２）
　前記制御部は、
　前記サーバ装置から前記通信端末を宛先とする前記第２のNon-IPデータを受信した際に、前記ＳＣＥＦエンティティに許容されている通信量もしくは通信レートを超過している場合、前記第２のNon-IPデータを廃棄する、付記１乃至１１のいずれか１項に記載のＳＣＥＦエンティティ。
　（付記１３）
　前記制御部は、
　前記第２のNon-IPデータが、前記通信端末の状態を示す前記第１のNon-IPデータを更新するNon-IPデータである場合、前記記憶部から前記第１のNon-IPデータを削除し、前記第２のNon-IPデータを前記記憶部へバッファさせる、付記１乃至１２のいずれか１項に記載のＳＣＥＦエンティティ。
　（付記１４）
　自装置が到達可能になるまでＳＣＥＦエンティティがバッファする複数のNon-IP データを、自装置が到達可能となった際に、制御装置を介して一つのメッセージとして受信する通信部と、
　前記一つのメッセージに含まれる複数のNon-IP データをそれぞれのNon-IP データ毎に読み取る制御部と、を備える通信端末。
　（付記１５）
　通信端末へ配送されなかった第１のNon-IPデータをバッファし、
　サーバ装置から前記通信端末を宛先とする第２のNon-IPデータを受信した際に、前記第１のNon-IPデータがバッファされている場合、前記第２のNon-IPデータをモバイルネットワーク内の制御装置へ送信することを抑制し、前記第２のNon-IPデータをバッファする、データ処理方法。
　（付記１６）
　自装置が到達可能になるまでＳＣＥＦエンティティがバッファする複数のNon-IP データを、自装置が到達可能となった際に、制御装置を介して一つのメッセージとして受信し、
　前記一つのメッセージに含まれる複数のNon-IP データをそれぞれのNon-IP データ毎に読み取る、データ受信方法。
　（付記１７）
　通信端末へ配送されなかった第１のNon-IPデータをバッファし、
　サーバ装置から前記通信端末を宛先とする第２のNon-IPデータを受信した際に、前記第１のNon-IPデータがバッファされている場合、前記第２のNon-IPデータをモバイルネットワーク内の制御装置へ送信することを抑制し、前記第２のNon-IPデータをバッファすることをコンピュータに実行させるプログラム。
　（付記１８）
　自装置が到達可能になるまでＳＣＥＦエンティティがバッファする複数のNon-IP データを、自装置が到達可能となった際に、制御装置を介して一つのメッセージとして受信し、
　前記一つのメッセージに含まれる複数のNon-IP データをそれぞれのNon-IP データ毎に読み取ることをコンピュータに実行させるプログラム。
　１０　ＳＣＥＦ
　１１　記憶部
　１２　制御部
　２０　制御装置
　２２　ＭＭＥ
　２４　ＳＧＳＮ
　２６　ＲＡＮ
　３０　サーバ装置
　３２　ＡＳ
　３４　ＳＣＳ
　４０　通信端末
　４２　ＵＥ
　４３　通信部
　４４　制御部

Claims (18)

  1. 　通信端末へ配送されなかった第１のNon-IPデータをバッファする記憶手段と、
    　サーバ装置から前記通信端末を宛先とする第２のNon-IPデータを受信した際に、前記第１のNon-IPデータがバッファされている場合、前記第２のNon-IPデータを前記記憶手段にバッファする制御手段と、を備えるＳＣＥＦエンティティ。
  2. 　前記制御手段は、
    　前記サーバ装置から前記第２のNon-IPデータを受信した際に、前記第１のNon-IPデータがバッファされているか否かを判定し、前記第１のNon-IPデータがバッファされていると判定した場合、前記第２のNon-IPデータを前記記憶手段にバッファし、前記第１のNon-IPデータがバッファされていないと判定した場合、制御装置へ前記第２のNon-IPデータを送信する、請求項１に記載のＳＣＥＦエンティティ。
  3. 　前記制御手段は、
    　前記制御装置から、前記通信端末へNon-IPデータを配送可能な状態であることを示すメッセージを受信すると、前記記憶手段にバッファされている前記第１及び第２のNon-IPデータを前記制御装置へ送信する、請求項１又は２に記載のＳＣＥＦエンティティ。
  4. 　前記制御手段は、
    　前記記憶手段にバッファされた順に、前記記憶手段にバッファされているNon-IPデータを、前記制御装置へ送信する、請求項３に記載のＳＣＥＦエンティティ。
  5. 　前記制御手段は、
    　前記記憶手段にバッファされている複数のNon-IPデータを含む１つのメッセージを前記制御装置へ送信する、請求項３又は４に記載のＳＣＥＦエンティティ。
  6. 　前記制御手段は、
    　前記サーバ装置に許容されている通信量もしくは通信レートを満たすように前記第１及び第２のNon-IPデータを前記制御装置へ送信する、請求項３乃至５のいずれか１項に記載のＳＣＥＦエンティティ。
  7. 　前記制御手段は、
    　前記サーバ装置から前記通信端末を宛先とする前記第２のNon-IPデータを受信した際に、前記サーバ装置に許容されている通信量もしくは通信レートを超過している場合、前記第２のNon-IPデータを廃棄する、請求項１乃至６のいずれか１項に記載のＳＣＥＦエンティティ。
  8. 　前記制御手段は、
    　前記通信端末または前記通信端末へNon-IPデータを伝送する通信ベアラに許容されている通信量もしくは通信レートを満たすように前記第１及び第２のNon-IPデータを前記制御装置へ送信する、請求項３乃至５のいずれか１項に記載のＳＣＥＦエンティティ。
  9. 　前記制御手段は、
    　前記サーバ装置から前記通信端末を宛先とする前記第２のNon-IPデータを受信した際に、前記通信端末または前記通信端末へNon-IPデータを伝送する通信ベアラに許容されている通信量もしくは通信レートを超過している場合、前記第２のNon-IPデータを廃棄する、請求項１乃至８のいずれか１項に記載のＳＣＥＦエンティティ。
  10. 　前記制御手段は、
    　前記通信端末または前記通信端末へNon-IPデータを伝送する前記通信ベアラに許容されている通信量もしくは通信レートに関する情報を、前記モバイルネットワーク内に配置されている加入者情報管理装置から受信する、請求項８又は９に記載のＳＣＥＦエンティティ。
  11. 　前記制御手段は、
    　前記ＳＣＥＦエンティティに許容されている通信量もしくは通信レートを満たすように前記第１及び第２のNon-IPデータを前記制御装置へ送信する、請求項３乃至５のいずれか１項に記載のＳＣＥＦエンティティ。
  12. 　前記制御手段は、
    　前記サーバ装置から前記通信端末を宛先とする前記第２のNon-IPデータを受信した際に、前記ＳＣＥＦエンティティに許容されている通信量もしくは通信レートを超過している場合、前記第２のNon-IPデータを廃棄する、請求項１乃至１１のいずれか１項に記載のＳＣＥＦエンティティ。
  13. 　前記制御手段は、
    　前記第２のNon-IPデータが、前記通信端末の状態を示す前記第１のNon-IPデータを更新するNon-IPデータである場合、前記記憶手段から前記第１のNon-IPデータを削除し、前記第２のNon-IPデータを前記記憶手段へバッファさせる、請求項１乃至１２のいずれか１項に記載のＳＣＥＦエンティティ。
  14. 　自装置が到達可能になるまでＳＣＥＦエンティティがバッファする複数のNon-IP データを、自装置が到達可能となった際に、制御装置を介して一つのメッセージとして受信する通信手段と、
    　前記一つのメッセージに含まれる複数のNon-IP データをそれぞれのNon-IP データ毎に読み取る制御手段と、を備える通信端末。
  15. 　通信端末へ配送されなかった第１のNon-IPデータをバッファし、
    　サーバ装置から前記通信端末を宛先とする第２のNon-IPデータを受信した際に、前記第１のNon-IPデータがバッファされている場合、前記第２のNon-IPデータをバッファする、データ処理方法。
  16. 　自装置が到達可能になるまでＳＣＥＦエンティティがバッファする複数のNon-IP データを、自装置が到達可能となった際に、制御装置を介して一つのメッセージとして受信し、
    　前記一つのメッセージに含まれる複数のNon-IP データをそれぞれのNon-IP データ毎に読み取る、データ受信方法。
  17. 　通信端末へ配送されなかった第１のNon-IPデータをバッファし、
    　サーバ装置から前記通信端末を宛先とする第２のNon-IPデータを受信した際に、前記第１のNon-IPデータがバッファされている場合、前記第２のNon-IPデータをバッファすることをコンピュータに実行させるプログラムが格納された非一時的なコンピュータ可読媒体。
  18. 　自装置が到達可能になるまでＳＣＥＦエンティティがバッファする複数のNon-IP データを、自装置が到達可能となった際に、制御装置を介して一つのメッセージとして受信し、
    　前記一つのメッセージに含まれる複数のNon-IP データをそれぞれのNon-IP データ毎に読み取ることをコンピュータに実行させるプログラムが格納された非一時的なコンピュータ可読媒体。
PCT/JP2017/036380 2016-10-07 2017-10-05 Ｓｃｅｆエンティティ、通信端末、データ処理方法、データ受信方法、及び非一時的なコンピュータ可読媒体 WO2018066668A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP21167314.0A EP3883271A1 (en) 2016-10-07 2017-10-05 Scef entity, communication terminal, data processing method, data receiving method, and non-transitory computer-readable medium
CN201780061580.7A CN109891918B (zh) 2016-10-07 2017-10-05 Scef实体、通信终端、数据处理方法、数据接收方法和非暂时性计算机可读介质
US16/339,808 US10911936B2 (en) 2016-10-07 2017-10-05 SCEF entity, communication terminal, data processing method, data receiving method, and non-transitory computer readable medium
EP17858504.8A EP3525497B1 (en) 2016-10-07 2017-10-05 Scef entity, communication terminal, data processing method, data receiving method, and non-transitory computer-readable medium
JP2018543973A JP6733736B2 (ja) 2016-10-07 2017-10-05 Ｓｃｅｆエンティティ及びデータ処理方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016-199093 2016-10-07
JP2016199093 2016-10-07

Publications (1)

Publication Number Publication Date
WO2018066668A1 true WO2018066668A1 (ja) 2018-04-12

Family

ID=61831771

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/036380 WO2018066668A1 (ja) 2016-10-07 2017-10-05 Ｓｃｅｆエンティティ、通信端末、データ処理方法、データ受信方法、及び非一時的なコンピュータ可読媒体

Country Status (5)

Country Link
US (1) US10911936B2 (ja)
EP (2) EP3525497B1 (ja)
JP (1) JP6733736B2 (ja)
CN (1) CN109891918B (ja)
WO (1) WO2018066668A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020088738A (ja) * 2018-11-29 2020-06-04 ソフトバンク株式会社 管理装置、通信システム、プログラム及び制御方法
JP2021162671A (ja) * 2020-03-31 2021-10-11 ソフトバンク株式会社 表示装置、送信システム、表示システム、表示方法及びプログラム

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10791443B2 (en) * 2017-03-03 2020-09-29 Verizon Patent And Licensing Inc. System and method for enhanced messaging using external identifiers
US10805178B2 (en) * 2017-11-27 2020-10-13 Cisco Technology, Inc. Subscription-based event notification techniques for reducing data buffering in mobile networks
US10805841B2 (en) 2018-07-23 2020-10-13 Cisco Technology, Inc. Policy enforcement methods and apparatus for background data transfers involving multiple UEs
US11323948B2 (en) * 2018-07-24 2022-05-03 T-Mobile Usa, Inc. Device management for NB-IoT devices
WO2020133406A1 (en) * 2018-12-29 2020-07-02 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for location based group message delivery
US11044605B2 (en) * 2019-05-10 2021-06-22 Verizon Patent And Licensing Inc. Network based non-IP data delivery service authorization for wireless networks
US10972368B2 (en) * 2019-05-17 2021-04-06 Oracle International Corporation Methods, systems, and computer readable media for providing reduced signaling internet of things (IoT) device monitoring
CN112218305B (zh) * 2019-07-09 2022-07-12 华为云计算技术有限公司 一种配置更新方法、通信装置和系统
US11381955B2 (en) 2020-07-17 2022-07-05 Oracle International Corporation Methods, systems, and computer readable media for monitoring machine type communications (MTC) device related information
US11895080B2 (en) 2021-06-23 2024-02-06 Oracle International Corporation Methods, systems, and computer readable media for resolution of inter-network domain names

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004165791A (ja) * 2002-11-11 2004-06-10 Fujitsu Ltd 複数の無線端末と通信可能な無線基地局用の装置、無線基地局と通信する無線端末、そのためのプログラムおよび方法
US20060285526A1 (en) * 2005-06-15 2006-12-21 Samsung Electronics Co., Ltd. Power saving apparatus and method in a wireless communication system
JP2009010628A (ja) * 2007-06-27 2009-01-15 Toshiba Corp 無線通信装置及び無線通信方法
JP2015523028A (ja) * 2012-07-02 2015-08-06 インテル・コーポレーション デバイストリガメッセージを効率的に送信するための装置及び方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101461971B1 (ko) * 2007-10-23 2014-11-20 엘지전자 주식회사 방송정보 전송방법
EP2477593A1 (de) * 2009-09-18 2012-07-25 Basf Se Verfahren zur herstellung von zubereitungen von in wasser schwer löslichen substanzen
US9894464B2 (en) * 2014-03-14 2018-02-13 Intel IP Corporation Conveyance of application communication patterns from an external application server to a 3rd generation partnership project system
US10051408B2 (en) * 2014-06-11 2018-08-14 Cisco Technology, Inc. Location reporting of user equipment in a cellular network environment
JP6509613B2 (ja) 2015-04-08 2019-05-08 日本車輌製造株式会社 ピン付きゴムブッシュ及びその組立て分解方法
KR102045408B1 (ko) * 2015-11-04 2019-11-15 엘지전자 주식회사 무선 통신 시스템에서 서빙 노드 이전 방법 및 이를 위한 장치
CN108702240B (zh) * 2016-02-18 2022-11-08 瑞典爱立信有限公司 用于管理控制平面优化的数据速率的系统、方法和装置
TR201911124T4 (tr) * 2016-03-31 2019-08-21 Ericsson Telefon Ab L M SCEF vasıtasıyla yüksek gecikmeli iletişim.

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004165791A (ja) * 2002-11-11 2004-06-10 Fujitsu Ltd 複数の無線端末と通信可能な無線基地局用の装置、無線基地局と通信する無線端末、そのためのプログラムおよび方法
US20060285526A1 (en) * 2005-06-15 2006-12-21 Samsung Electronics Co., Ltd. Power saving apparatus and method in a wireless communication system
JP2009010628A (ja) * 2007-06-27 2009-01-15 Toshiba Corp 無線通信装置及び無線通信方法
JP2015523028A (ja) * 2012-07-02 2015-08-06 インテル・コーポレーション デバイストリガメッセージを効率的に送信するための装置及び方法

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical I Specification Group Services and System Aspects; Architecture enhancements to facilitate communications with packet data networks and applications (Release 14", 3GPP TS 23.682 V14.2.0, December 2016 (2016-12-01), pages 86 - 88, XP051230005 *
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements to facilitate communications with packet data networks and applications (Release 14", 3GPP TS 23.682 V14.1.0, September 2016 (2016-09-01), pages 82 - 85, XP051172579 *
ALCATEL -LUCENT ET AL.: "HLCOM Solution based on DL buffering in SGW", A WG2#106 S2-144597, November 2014 (2014-11-01), pages 1 - 2, XP050923972, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_106_San_Francisco/Docs/S2-144597.zip> *
ERICSSON ET AL.: "HLCOM and eDRX for NIDD via SCEF", SA WG2 MEETING #114, S2-161935, April 2016 (2016-04-01), XP051092120, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_114_Sophia_Antipolis/Docs/S2-161935.zip> *
NEC: "Corrections for MT NIDD procedure to handle multiple non-IP data", SA WG2 MEETING #S2-117, S2-165760, 11 October 2016 (2016-10-11), XP051169734, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_117_Kaohsiung_City/Docs/S2-165760.zip> *
NOKIA ET AL.: "Corrections for MT NIDD procedure to handle multiple non-IP data", SA WG2 MEETING #S2-118, S2-166631, 8 November 2016 (2016-11-08), XP051199603 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020088738A (ja) * 2018-11-29 2020-06-04 ソフトバンク株式会社 管理装置、通信システム、プログラム及び制御方法
JP2021162671A (ja) * 2020-03-31 2021-10-11 ソフトバンク株式会社 表示装置、送信システム、表示システム、表示方法及びプログラム
JP7241047B2 (ja) 2020-03-31 2023-03-16 ソフトバンク株式会社 表示装置、送信システム、表示システム、表示方法及びプログラム

Also Published As

Publication number Publication date
EP3525497A4 (en) 2019-08-14
EP3883271A1 (en) 2021-09-22
EP3525497A1 (en) 2019-08-14
JP6733736B2 (ja) 2020-08-05
EP3525497B1 (en) 2021-04-21
US20190230492A1 (en) 2019-07-25
CN109891918B (zh) 2021-08-10
CN109891918A (zh) 2019-06-14
JPWO2018066668A1 (ja) 2019-06-27
US10911936B2 (en) 2021-02-02

Similar Documents

Publication Publication Date Title
JP6733736B2 (ja) Ｓｃｅｆエンティティ及びデータ処理方法
US11310697B2 (en) Core node, base station, radio terminal, communication method, radio resource allocation method, base station selection method, and readable medium
JP6693572B2 (ja) システム、制御装置、Ｅｘｐｏｓｕｒｅ Ｆｕｎｃｔｉｏｎエンティティ、及び方法
EP3525532B1 (en) Control device, paging method, and non-transitory computer-readable medium
JP7401111B2 (ja) 基地局及び基地局の方法
WO2018084231A1 (ja) ゲートウェイ装置、移動管理装置、基地局、通信方法、制御方法、ページング方法、及びコンピュータ可読媒体
JP2019029912A (ja) 制御装置、通信端末、サービス制御装置、通信システム、データ送信方法、及びプログラム
JP7376166B2 (ja) 第１のｃｎノード、第１のｃｎノードにおいて実行される方法、及びｕｅにおいて実行される方法
WO2018124278A1 (ja) 通信端末、制御装置、通信システム、及び通信方法
CN111526602B (zh) 无线通信中在拥塞控制下发送用户数据的方法和装置
JP6583531B2 (ja) コアノード、無線端末、及び通信方法

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2018543973

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017858504

Country of ref document: EP

Effective date: 20190507