发明名称:通信系统申请日:2013年4月23日申请号:201380021938.5(PCT/JP2013/061874)
技术领域：
：本发明涉及一种具备与网络连接的基站装置、以及可与基站装置进行无线通信的通信终端装置的通信系统。
背景技术：
：：在被称为第3代的通信方式中，日本从2001年起开始了W-CDMA(WidebandCodedivisionMultipleAccess，宽带码分多址)方式的商用服务。此外，通过向下行链路(专用数据信道、专用控制信道)追加分组传送用的信道(HighSpeed-DownlinkSharedChannel：HS-DSCH，高速下行共享信道)，开始了HSDPA(HighSpeedDownlinkPacketAccess，高速下行分组接入)的服务，这项服务实现了使用下行链路的数据发送的进一步高速化。进而，为了使上行方向的数据发送进一步高速化，还开始了HSUPA(HighSpeedUplinkPacketAccess，高速上行分组接入)方式的服务。W-CDMA是由移动通信系统的标准化团体3GPP(3rdGenerationPartnershipProject，第三代合作伙伴计划)所规定的通信方式，汇总在第10版公开的标准手册中。另外，3GPP还在探讨新的通信方式，以作为与W-CDMA不同的通信方式，这种通信方式对于无线区间称为长期演进(LongTermEvolution:LTE)，对包含核心网络以及无线接入网(以下统称网络)的系统整体结构称为系统架构演进(SystemArchitectureEvolution:SAE)。该通信方式也被称为3.9G(3.9Generation)系统。在LTE中，接入方式、无线的信道结构和协议与W-CDMA(HSDPA/HSUPA)完全不同。例如，关于接入方式，W-CDMA使用的是码分多址接入(CodeDivisionMultipleAccess)，而LTE在下行方向使用的是OFDM(OrthogonalFrequencyDivisionMultiplexing，正交频分复用)，在上行方向使用的是SC-FDMA(SingleCarrierFrequencyDivisionMultipleAccess，单载波频分多址)。另外，关于带宽，W-CDMA是5MHz，与之相对，在LTE中每个基站可在1.4MHz、3MHz、5MHz、10MHz、15MHz、20MHz中进行选择。另外，LTE与W-CDMA不同，其仅有分组通信方式，不包含线路交换。由于LTE使用与W-CDMA的核心网络GPRS(GeneralPacketRadioService，通用分组无线业务)不同的新的核心网络来构成通信系统，因此LTE的无线接入网(无线接入网络(radioaccessnetwork))被定义为与W-CDMA网不同的独立的无线接入网。因此，为了与W-CDMA的通信系统进行区别，在LTE的通信系统中，将核心网络称为EPC(EvolvedPacketCore，演进的分组核心)，将无线接入网络称为E-UTRAN(EvolvedUniversalTerrestrialRadioAccessNetwork，演进的通用陆基无线接入)。此外，在无线接入网络中，将与作为通信终端装置的移动终端(UserEquipment:UE)进行通信的基站(Basestation)称为eNB(E-UTRANNodeB)。与多个基站进行控制数据以及用户数据交换的基站控制装置(RadioNetworkController，无线网络控制器)的功能由EPC承担。EPC又称为aGW(AccessGateway，接入网关)。由EPC和E-UTRAN构成的系统称为EPS(EvolvedPacketSystem，演进的分组系统)。在LTE的通信系统中，提供有单播(Unicast)服务和E-MBMS服务(EvolvedMultimediaBroadcastMulticastService，演进的多媒体广播多播服务)。E-MBMS服务是广播型多媒体服务。E-MBMS服务有时仅称作MBMS。E-MBMS服务对多个移动终端发送新闻和天气预报、以及移动广播等大容量广播内容。这也称作点对多点(PointtoMultipoint)服务。3GPP中与LTE系统的整体架构(Architecture)相关的决定事项在非专利文献1(第4章)中有记载。以下使用图1说明整体架构。图1是表示LTE方式的通信系统的结构的说明图。图1中，若对于移动终端101的控制协议，例如RRC(RadioResourceControl，无线资源控制)和用户层面，例如PDCP(PacketDataConvergenceProtocol，分组数据汇聚协议)、RLC(RadioLinkControl，无线链路控制)、MAC(MediumAccessControl，媒体接入控制)、PHY(Physicallayer，物理层)在基站102终止，则E-UTRAN由一个或者多个基站102构成。基站102对从移动性管理实体(MobilityManagementEntity：MME)103通知的寻呼信号(PagingSignal、也称为寻呼消息(pagingmessages))进行调度(Scheduling)及发送。基站102利用X2接口互相连接。另外，基站102利用S1接口与EPC(EvolvedPacketCore)连接。更明确而言，基站102利用S1_MME接口与MME(MobilityManagementEntity)103连接，利用S1_U接口与S-GW(ServingGateway，服务网关)104连接。MME103向多个或者单个基站102进行寻呼信号的分配。另外，MME103进行待机状态(IdleState：空闲状态)的移动性控制(Mobilitycontrol)。在移动终端处于待机状态及活动状态(ActiveState)时，MME103对跟踪区域(TrackingArea)列表进行管理。S-GW104与一个或者多个基站102进行用户数据的收发。在基站间的移交时，S-GW104成为本地的移动性的定位点(MobilityAnchorPoint)。在EPC中还存在P-GW(PDNGateway，PDN网关)。P-GW对每个用户进行分组过滤、UE-ID地址的分配等。移动终端101与基站102之间的控制协议RRC进行广播(Broadcast)、寻呼(paging)、RRC连接管理(RRCconnectionmanagement)等。作为RRC中的基站和移动终端的状态，有RRC_IDLE和RRC_CONNECTED。在RRC_IDLE下，进行PLMN(PublicLandMobileNetwork，公众陆地移动网络)选择、系统信息(SystemInformation:SI)的广播、寻呼(paging)、小区重选(cellre-selection)、移动性管理等。在RRC_CONNECTED下，移动终端具有RRC连接(connection)，能够与网络进行数据的收发。另外，在RRC_CONNECTED下，还进行移交(Handover:HO)、邻近小区(Neighbourcell)的测定等。下面利用图2来说明非专利文献1(第5章)中记载的3GPP中的关于LTE系统的帧结构的决定事项。图2是表示在LTE方式的通信系统中使用的无线帧的结构的说明图。图2中，1个无线帧(Radioframe)是10ms。无线帧被分割为10个大小相等的子帧(Sub-frame)。子帧被分割为2个大小相等的时隙(slot)。每个无线帧中第1和第6个子帧包含下行同步信号(DownlinkSynchronizationSignal:SS)。同步信号包含第一同步信号(PrimarySynchronizationSignal:P-SS)和第二同步信号(SecondarySynchronizationSignal:S-SS)。以子帧为单位进行MBSFN(MultimediaBroadcastmulticastserviceSingleFrequencyNetwork，多媒体广播多播服务单频网络)用信道和MBSFN以外的信道的多路复用。MBSFN发送(MBSFNTransmission)是指，是同时从多个小区通过相同波形的发送而实现的同时广播发送技术(simulcasttransmissiontechnique)。来自MBSFN区域(MBSFNArea)的多个小区的MBSFN发送在移动终端被识别为1个发送。MBSFN就是支持这种MBSFN发送的网络。以下，将MBSFN发送用的子帧称为MBSFN子帧(MBSFNsubframe)。在非专利文献2中，记载了分配MBSFN子帧时的信令例。图3是表示MBSFN帧的结构的说明图。如图3所示，对每个分配周期(radioFrameAllocationPeriod，无线帧分配期间)分配包含MBSFN子帧的无线帧。MBSFN子帧是在根据分配周期和分配偏移(radioFrameAllocationOffset，无线帧分配偏移)而定义的无线帧中为了MBSFN而分配的子帧，是用于传输多媒体数据的子帧。满足以下式(1)的无线帧就是包含MBSFN子帧的无线帧。SFNmodradioFrameAllocationPeriod＝radioFrameAllocationOffset…(1)MBSFN子帧的分配以6位来进行。最左的位定义第2个子帧(#1)的MBSFN分配。左起第2位定义第3个子帧(#2)的MBSFN分配，左起第3位定义第4个子帧(#3)的MBSFN分配，左起第4位定义第7个子帧(#6)的MBSFN分配，左起第5位定义第8个子帧(#7)的MBSFN分配，左起第6位定义第9个子帧(#8)的MBSFN分配。在该位表示“1”的情况下，表示对应的子帧被分配为用于MBSFN。3GPP中与LTE系统的信道结构相关的决定事项在非专利文献1(第5章)中有记载。设想在CSG(ClosedSubscriberGroup，封闭用户组)小区中也使用与non-CSG小区相同的信道结构。关于物理信道(Physicalchannel)，使用图4进行说明。图4是说明在LTE方式的通信系统中使用的物理信道的说明图。在图4中，物理广播信道(PhysicalBroadcastchannel:PBCH)401是用于从基站102向移动终端101进行下行发送的信道。BCH传输块(transportblock)映射到40ms间隔中的4个子帧。没有40ms定时的明确的信令。物理控制格式指示信道(PhysicalControlFormatIndicatorChannel：PCFICH)402是用于从基站102向移动终端101进行下行发送的信道。PCFICH针对为了PDCCHs而使用的OFDM码元的数量从基站102向移动终端101进行通知。PCFICH按照每个子帧进行发送。物理下行控制信道(PhysicalDownlinkControlChannel：PDCCH)403是用于从基站102向移动终端101进行下行发送的信道。PDCCH对下述图5所示的传输信道之一的下行共享信道(DownlinkSharedChannel：DL-SCH)的资源分配(allocation)信息、图5所示的传输信道之一的寻呼信道(PagingChannel：PCH)的资源分配(allocation)信息、DL-SCH相关的HARQ(HybridAutomaticRepeatreQuest，混合自动重传请求)信息进行通知。PDCCH对上行调度准许(UplinkSchedulingGrant)进行输送。PDCCH输送对于上行发送的响应信号即Ack(Acknowledgement，确认)/Nack(NegativeAcknowledgement，否定确认)。PDDCH也称为L1/L2控制信号。物理下行共享信道(PhysicalDownlinkSharedChannel：PDSCH)404是用于从基站102向移动终端101进行下行发送的信道。作为传输信道的下行共享信道(DL-SCH)以及作为传输信道的PCH被映射到PDSCH。物理多播信道(PhysicalMulticastChannel：PMCH)405是用于从基站102向移动终端101进行下行发送的信道。作为传输信道的多播信道(MulticastChannel：MCH)被映射到PMCH。物理上行控制信道(PhysicalUplinkControlChannel：PUCCH)406是用于从移动终端101向基站102进行上行发送的信道。PUCCH输送对于下行发送的响应信号(responsesignal)即Ack/Nack。PUCCH对CQI(ChannelQualityIndicator，信道质量指示)报告进行输送。CQI是表示所接收到的数据的品质、或通信路径品质的品质信息。此外，PUCCH对调度请求(SchedulingRequest：SR)进行输送。物理上行共享信道(PhysicalUplinkSharedChannel：PUSCH)407是用于从移动终端101向基站102进行上行发送的信道。图5所示的传输信道之一的上行共享信道(UplinkSharedChannel：UL-SCH)被映射到PUSCH。物理HARQ指示信道(PhysicalHybridARQIndicatorChannel:PHICH)408是用于从基站102向移动终端101进行下行发送的信道。PHICH输送对于上行发送的响应信号即Ack/Nack。物理随机接入信道(PhysicalRandomAccessChannel：PRACH)409是用于从移动终端101向基站102进行上行发送的信道。PRACH对随机接入前导(randomaccesspreamble)进行输送。下行参考信号(Referencesignal：RS)是移动通信系统中已知的码元。定义了以下5种下行参考信号。小区固有参考信号(Cell-specificReferenceSignals：CRSs)、MBSFN参考信号(MBSFNreferencesignals)、UE固有参考信号(UE-specificreferencesignals)即解调用参考信号(DemodulationReferenceSignals：DM-RSs)、定位参考信号(PositioningReferenceSignals：PRSs)、信道信息参考信号(Channel-StateInformationReferenceSignals：CSI-RSs)。作为移动终端的物理层的测定，有参考码元的接收功率(ReferenceSignalReceivedPower：RSRP)测定。针对非专利文献1(第5章)中记载的传输信道(Transportchannel)，使用图5进行说明。图5是说明在LTE方式的通信系统中使用的传输信道的说明图。图5(A)表示下行传输信道和下行物理信道间的映射。图5(B)表示上行传输信道和上行物理信道间的映射。在图5(A)所示的下行传输信道中，广播信道(BroadcastChannel：BCH)对其基站(小区)的整个覆盖范围进行广播。BCH被映射到物理广播信道(PBCH)。下行共享信道(DownlinkSharedChannel：DL-SCH)使用基于HARQ(HybridARQ)的重传控制。DL-SCH能够向基站(小区)的整个覆盖范围进行广播。DL-SCH支持动态或准静态(Semi-static)的资源分配。准静态的资源分配也称为持续调度(PersistentScheduling)。为了降低移动终端的功耗，DL-SCH支持移动终端的不连续接收(Discontinuousreception：DRX)。DL-SCH向物理下行共享信道(PDSCH)进行映射。寻呼信道(PagingChannel：PCH)为了能够实现移动终端的低功耗，支持移动终端的DRX。要求PCH向基站(小区)的整个覆盖范围进行广播。PCH向能够动态地利用于业务的物理下行共享信道(PDSCH)那样的物理资源进行映射。多播信道(MulticastChannel：MCH)用于向基站(小区)的整个覆盖范围进行广播。MCH支持多小区发送中的MBMS服务(MTCH与MCCH)的SFN合成。MCH支持准静态的资源分配。MCH向PMCH进行映射。在图5(B)所示的传输信道中，上行共享信道(UplinkSharedChannel：UL-SCH)使用基于HARQ(HybridARQ)的重传控制。UL-SCH支持动态或准静态(Semi-static)的资源分配。UL-SCH向物理上行共享信道(PUSCH)进行映射。图5(B)所示的随机接入信道(RandomAccessChannel：RACH)仅限于控制信息。RACH存在冲突的风险。RACH向物理随机接入信道(PRACH)进行映射。以下对HARQ进行说明。所谓HARQ是利用自动重传请求(AutomaticRepeatreQuest：ARQ)与纠错(ForwardErrorCorrection)的组合，使传输路径的通信质量提高的技术。HARQ的优点在于，即便对于通信质量发生变化的传输路径，也能利用重传使纠错有效发挥作用。特别是，在重传时可通过将初传的接收结果与重传的接收结果进行合成，从而进一步提高品质。下面对重传方法的一例进行说明。在接收侧不能正确地对接收到的数据进行解码时，换言之，在发生了CRC(CyclicRedundancyCheck，循环冗余校验)错误时(CRC＝NG)，会从接收侧向发送侧发送“Nack”。接收到“Nack”的发送侧将对数据进行重传。在接收侧能正确地对接收到的数据进行解码时，换言之，在未发生CRC错误时(CRC＝OK)，会从接收侧向发送侧发送“Ack”。接收到“Ack”的发送侧发送下一数据。作为HARQ方式的一例，有追赶合并(ChaseCombining)。所谓追赶合并是在初传与重传中发送相同数据，通过在重传中进行初传数据与重传数据的合成来使增益提高的方式。追赶合并基于如下的思路：即便在初传数据中有错误，但也包含部分正确的数据，通过将正确部分的初传数据与重传数据合成，便能够以更高精度发送数据。此外，作为HARQ方式的其它示例，有IR(IncrementalRedundancy，递增冗余)。所谓IR是使冗余度增加，通过在重传中发送校验位，从而与初传组合，使冗余度增加，由此利用纠错功能来提高品质。针对非专利文献1(第6章)中记载的逻辑信道(Logicalchannel)，使用图6进行说明。图6是说明LTE方式的通信系统中使用的逻辑信道的说明图。图6(A)中表示了下行逻辑信道与下行传输信道之间的映射。图6(B)中表示了上行逻辑信道与上行传输信道之间的映射。广播控制信道(BroadcastControlChannel：BCCH)是广播系统控制信息用的下行信道。将作为逻辑信道的BCCH向作为传输信道的广播信道(BCH)、或下行共享信道(DL-SCH)进行映射。寻呼控制信道(PagingControlChannel：PCCH)是用于发送寻呼信息(PagingInformation)以及系统信息(SystemInformation)的变更的下行信道。PCCH用于网络不知道移动终端的小区位置的情况。作为逻辑信道的PCCH向作为传输信道的寻呼信道(PCH)进行映射。共享控制信道(CommonControlChannel：CCCH)是用于移动终端与基站之间的发送控制信息的信道。CCCH用于移动终端在与网络之间不具有RRC连接(connection)的情况。在下行方向，CCCH向作为传输信道的下行共享信道(DL-SCH)进行映射。在上行方向，CCCH向作为传输信道的上行共享信道(UL-SCH)进行映射。多播控制信道(MulticastControlChannel：MCCH)是用于一对多发送的下行信道。MCCH是用于从网络向移动终端发送一个或几个MTCH用的MBMS控制信息的信道。MCCH仅用于正在接收MBMS的移动终端。MCCH向作为传输信道的多播信道(MCH)进行映射。专用控制信道(DedicatedControlChannel：DCCH)是以1对1的方式，对移动终端与网络之间的专用控制信息进行发送的信道。DCCH用于移动终端为RRC连接(connection)的情况。在上行中DCCH向上行共享信道(UL-SCH)进行映射，在下行中DCCH映射到下行共享信道(DL-SCH)。专用业务信道(DedicatedTrafficChannel：DTCH)是向用于发送用户信息的专用移动终端进行一对一通信的信道。DTCH在上行以及下行中均存在。在上行中DTCH向上行共享信道(UL-SCH)进行映射，在下行中DTCH向下行共享信道(DL-SCH)进行映射。多播业务信道(MulticastTrafficchannel：MTCH)是用于从网络向移动终端发送业务数据的下行信道。MTCH是仅用于正在接收MBMS的移动终端的信道。MTCH向多播信道(MCH)进行映射。所谓GCI，就是小区全球识别符(CellGlobalIdentifier)。ECGI是指E-UTRAN小区全球识别符(E-UTRANCellGlobalIdentifier)。在LTE、后述的LTE-A(LongTermEvolutionAdvanced，高级长期演进)以及UMTS(UniversalMobileTelecommunicationSystem，通用移动通信系统)中导入CSG(ClosedSubscriberGroup：封闭用户组)小区。下面说明CSG小区(参考非专利文献3的第3.1章)。所谓CSG(ClosedSubscriberGroup)小区是运营商对能够利用的加入者进行指定的小区(以下有时称为“指定加入者用小区”)。被指定的加入者被允许接入PLMN(PublicLandMobileNetwork：公众陆地移动网络)中的一个以上的小区。将允许被指定的加入者接入的一个以上小区称为“CSG小区(CSGcell(s))”。但是，PLMN存在接入限制。CSG小区对固有的CSG身份(CSGidentity：CSGID；CSG-ID)进行广播，是利用CSG指示(CSGIndication)广播“TRUE”的PLMN的一部分。事先进行利用注册，被允许的加入者组的成员使用作为接入允许信息的CSG-ID来接入CSG小区。CSG-ID由CSG小区或小区来广播。在移动通信系统中存在多个CSG-ID。而且，为了简化CSG关联成员的接入，可利用移动终端(UE)来使用CSG-ID。移动终端的位置跟踪以由一个以上的小区构成的区域为单位来进行。位置跟踪的目的是为了即便在待机状态也能跟踪移动终端的位置并呼叫移动终端，也就是呼入移动终端。该移动终端的位置跟踪用的区域称为跟踪区域。所谓CSG白名单(CSGWhiteList)是记录有加入者所属的CSG小区的全部CSGID、并存储在USIM(UniversalSubscriberIdentityModule，通用用户识别模块)中的列表。CSG白名单有时也被简称为白名单或允许的CSG列表(AllowedCSGList)。在通过CSG小区的移动终端的接入中，MME执行接入控制(accesscontrol)(参考非专利文献4的第4.3.1.2章)。作为移动终端的接入具体例，有附着(attach)、联合附着(combinedattach)、分离(detach)、服务请求(servicerequest)、跟踪区域更新流程(TrackingAreaUpdateprocedure)等(参考非专利文献4的第4.3.1.2章)。以下对待机状态下移动终端的服务类型进行说明(参考非专利文献3的第4.3章)。待机状态下移动终端的服务类型有有限服务(Limitedservice，也称为受限服务)、标准服务(正常服务(Normalservice))、运营商服务(Operatorservice)。有限服务是指后述的可接受小区上的紧急呼叫(Emergencycalls)、ETWS(EarthquakeandTsunamiWarningSystem，地震和海啸预警系统)、CMAS(CommercialMobileAlertSystem，商业移动预警系统)。标准服务(也称为正常服务)是指后述的合适小区上的公共服务。运营商服务是指后述的保留小区上的仅用于运营商的服务。以下说明“合适小区(Suitablecell)”。所谓“合适小区(Suitablecell)”是指，UE为接受正常(normal)服务而可能进行驻扎(CampON)的小区。这种小区应满足以下(1)、(2)的条件。(1)小区是所选择的PLMN或注册的PLMN、或“EquivalentPLMN列表(等价PLMN列表)”的PLMN的一部分。(2)根据NAS(Non-AccessStratum，非接入层面)所提供的最新信息，进一步满足以下(a)～(d)的条件。(a)该小区不是被禁止(barred)小区。(b)该小区不是“被禁止漫游的LAs”列表的一部分，而是跟踪区域(TrackingArea：TA)的一部分。此时，该小区必需满足上述(1)。(c)该小区满足小区选择评价基准。(d)该小区根据系统信息(SystemInformation:SI)被确定为CSG小区时，CSG-ID是UE的“CSG白名单”(CSGWhiteList)的一部分，即包含于UE的CSGWhiteList中。下面，说明“可接受小区(Acceptablecell)”。所谓“可接受小区(Acceptablecell)”是指，UE为了接受有限业务而可能驻扎的小区。这种小区应满足以下(1)、(2)所有的条件。(1)该小区不是被禁止的小区(也称为“被禁止小区(Barredcell)”)。(2)该小区满足小区选择评价基准。“被禁止小区(Barredcell)”由系统信息进行指示。“保留小区(Reservedcell)”由系统信息进行指示。所谓“驻扎在小区(campon)”是指，UE结束小区选择(cellselection)或小区重选(cellreselection)的处理，从而处于UE选择了对系统信息和寻呼信息进行监控的小区的状态。UE进行驻扎的小区有时称为“服务小区(Servingcell)”。在3GPP中，研究了称为Home-NodeB(Home-NB；HNB)、Home-eNodeB(Home-eNB；HeNB)的基站。UTRAN中的HNB以及E-UTRAN中的HeNB是面向例如家庭、法人、商业用的接入服务的基站。非专利文献5中公开了向HeNB及HNB进行接入的3种不同模式。具体而言，公开了开放接入模式(Openaccessmode)、闭合接入模式(Closedaccessmode)、以及混合接入模式(Hybridaccessmode)。各个模式具有以下特征。在开放接入模式下，HeNB、HNB作为普通的运营商的正常小区被操作。在封闭接入模式下，HeNB、HNB作为CSG小区被操作。该CSG小区是仅CSG成员可接入的CSG小区。在混合接入模式下，HeNB、HNB作为非CSG成员也同时被允许接入的CSG小区被操作。换言之，混合接入模式的小区(也称作混合小区)是支持开放接入模式和封闭接入模式这两个模式的小区。3GPP中，在所有PCI(PhysicalCellIdentity，物理小区身份)中，存在为了在CSG小区中使用而通过网络预约的PCI范围(参考非专利文献1的第10.5.1.1章)。PCI范围的分割有时也称为PCI拆分。PCI拆分的相关信息(也称为PCI拆分信息)根据系统信息从基站向覆盖范围内的移动终端进行广播。基站的覆盖范围内表示将该基站作为服务小区。非专利文献6公开了使用PCI拆分的移动终端的基本动作。不具有PCI拆分信息的移动终端需要使用全部PCI，例如全部504代码，来进行小区搜索。相对于此，具有PCI拆分信息的移动终端能够使用该PCI拆分信息进行小区搜索。此外，在3GPP中，作为版本10，推进了高级长期演进(LongTermEvolutionAdvanced：LTE-A)的标准制定(参考非专利文献7、非专利文献8)。在LTE-A系统中，为了得到高的通信速度、在小区边缘的高处理能力、新的覆盖范围区等，研究了对中继(Relay)以及中继节点(RelayNode：RN)的支持。作为中继装置的中继节点经由被称为施主小区(Donorcell，以下有时称为“施主eNB(DonoreNB；DeNB)”)的小区与无线接入网络进行无线连接。在施主小区的范围内，从网络(Network：NW)向中继节点的链路共用与从网络向UE的链路相同的频带(band)。在该情况下，支持3GPP版本8的UE也能够连接至该施主小区。施主小区和中继节点之间的链路称作回程链路(backhaullink)，中继节点和UE之间的链路称为接入链路(accesslink)。作为FDD(FrequencyDivisionDuplex，频分双工)中的回程链路的多路复用方法，从DeNB向RN的发送在下行(DL)频带进行，从RN向DeNB的发送在上行(UL)频带进行。作为在中继中的资源分配方法，从DeNB向RN的链路以及从RN向UE的链路在一个频带中时分多路复用，从RN向DeNB的链路以及从UE向RN的链路也在一个频带中时分多路复用。这样，在中继时，能够防止中继的发送与该中继的接收发生干扰。在3GPP中，不仅针对通常的eNB(宏小区)，还对微微eNB(微微小区(picocell))、HeNB(HNB、CSG小区)、热区小区用的节点、中继节点、远端射频头(RemoteRadioHead：RRH)、转发器等所谓的本地节点进行了研究。上述由各种类型的小区构成的网络也称为异构网络(heterogeneousnetwork)。LTE中，可用于通信的频带(以下有时称为“工作频带”)被事先确定。非专利文献9中记载了该频带。在LTE-A系统中，为了支持高达100MHz的更宽的频带宽度(transmissionbandwidths)，研究了整合(也称为聚合(aggregation))两个以上分量载波(ComponentCarrier：CC)的载波聚合(CarrierAggregation：CA)。支持LTE即支持3GPP版本8或9的UE只能在相当于一个服务小区的一个CC上进行数据收发。相对于此，可认为支持3GPP版本10的UE具有可以在相当于多个服务小区的多个CC上同时进行数据收发、或者仅接收、或仅发送的能力(capability)。各CC使用3GPP版本8或9的结构，CA支持连续CC、非连续CC以及不同频带宽度的CC。UE构成上行链路的CC(ULCC)的数量不可能超过下行链路的CC(DLCC)的数量。由同一eNB构成的CC无需提供相同的覆盖范围。CC与3GPP版本8或9具有兼容性。在CA中，无论上行链路还是下行链路，每个服务小区都有一个独立的HARQ实体。每个服务小区对每个TTI都会创建传输块。各传输块与HARQ重传被映射到单个服务小区。构成CA时，UE与NW具有唯一的RRC连接(RRCconnection)。在RRC连接中，一个服务小区会提供NAS移动性信息与安全输入。该小区称作主小区(PrimaryCell:PCell)。下行链路中与PCell对应的载波是下行主分量载波(DownlinkPrimaryComponentCarrier:DLPCC)。上行链路中与PCell对应的载波是上行主分量载波(UplinkPrimaryComponentCarrier:ULPCC)。根据UE的能力(capability)，为了形成PCell和服务小区的组而构成从小区(SecondaryCell：SCell)。下行链路中与SCell对应的载波是下行从分量载波(DownlinkSecondaryComponentCarrier:DLSCC)。上行链路中与SCell对应的载波是上行从分量载波(UplinkSecondaryComponentCarrier:ULSCC)。对于一个UE，构成由一个PCell和一个以上的SCell组成的服务小区的组。3GPP中，作为更加先进的新型无线区间的通信方式，研究了上述的高级LTE(LTEAdvanced：LTE-A)(参考非专利文献7及非专利文献8)。LTE-A以LTE的无线区间通信方式为基础，在该基础上添加了一些新技术而构成。作为新技术，有支持更大带宽的技术(Widerbandwidthextension，带宽扩展)以及多地点协作发送接收(CoordinatedMultiplePointtransmissionandreception：CoMP)技术等。关于3GPP中为LTE-A而研究的CoMP，在非专利文献10中有记载。CoMP是指，通过在地理上分离的多地点之间进行协作的发送或接收，来扩大高数据率的覆盖范围、提高小区边缘的处理能力以及提高通信系统中的处理能力的技术。CoMP中有下行CoMP(DLCoMP)和上行CoMP(ULCoMP)。利用DLCoMP，在多地点(多点)间协作地向一个移动终端(UE)发送PDSCH。向一个UE发送的PDSCH可以从多点中的一个点发送，也可以从多点中的多个点发送。DLCoMP中，服务小区是指由PDCCH发送资源分配的单独小区。作为DLCoMP的方法，研究了联合处理(JointProcessing：JP)、协作调度(CoordinatedScheduling：CS)或协作波束赋形(CoordinatedBeamforming：CB)(以下有时称为“CS/CB”)。JP可以在CoMP协作集(CoMPcooperatingset)中的各个点利用数据。JP有联合发送(JointTransmission：JT)和动态节点选择(DynamicPointSelection：DPS)。DPS包含动态小区选择(DynamicCellSelection：DCS)。利用JT，在某个时间点从多个点，具体而言就是从CoMP协作集(CoMPcooperatingset)的一部分或全部进行PDSCH的发送。利用DPS，在某个时间点从CoMP协作集内的1个点进行PDSCH的发送。CS/CB仅可用于由服务小区进行的数据发送。利用CS/CB，配合与CoMP协作集对应的小区之间的调整，确定用户调度或波束赋形。作为利用多点进行数据收发的点，研究了单元及小区，作为单元及小区，研究了基站(NB、eNB、HNB、HeNB)、RRU(RemoteRadioUnit，远端无线单元)、RRE(RemoteRadioEquipment，远端无线设备)、RRH(RemoteRadioHead，远端射频头)、中继节点(RelayNode：RN)等。进行多地点协作发送的单元及小区有时分别称为多点单元、多点小区。现有技术文献非专利文献非专利文献1:3GPPTS36.300V10.5.0非专利文献2:3GPPTS36.331V10.3.0非专利文献3:3GPPTS36.304V10.3.0第3.1章、4.3章、5.2.4章非专利文献4:3GPPTR23.830V9.0.0非专利文献5:3GPPS1-083461非专利文献6:3GPPR2-082899非专利文献7:3GPPTR36.814V9.0.0非专利文献8:3GPPTR36.912V10.0.0非专利文献9:3GPPTS36.101V10.3.0非专利文献10:3GPPTR36.819V11.0.0非专利文献11:3GPPTR23.888V1.6.0非专利文献12:3GPPTR22.801V12.0.0非专利文献13:3GPPTS23.401V11.0.0非专利文献14:3GPPTS24.301V11.1.0非专利文献15:3GPPR2-120444非专利文献16:3GPPS2-114341技术实现要素：发明所要解决的技术问题由于以上述3GPP标准为代表的蜂窝系列无线通信的发展，使用该无线网络的各种方式的应用之间已开展或正试图开展通信。例如3GPP中的机器类通信(MachineTypeCommunication；简称：MTC)、以及IEEE802.3标准等设想进行有线通信的应用之间的通信等。这种应用的使用环境和方式与过去移动通信中的设想不同，因此会引发各种课题以及问题。例如，进行MTC的通信终端装置(以下称为“MTC终端”)，作为使用环境，考虑会设置于煤气表或动物等(参考非专利文献11)。此时，由于MTC终端是由电池驱动，因此必须考虑到电池更换以及再充电困难的情况。因此，与通常的通信终端装置相比，消耗的功率必须更低。此外，还需要考虑到盗窃以及损坏等风险，因此必须对MTC终端进行监控。此外，在与MTC不同的应用中，在利用HTTP(HyperTextTransferProtocol，超文本传输协议)以及TCP(TransmissionControlProtocol，传输控制协议)的通信等中，仅为了监视成为通信的端到端(End-End)的应用之间的会话连接，有时会定期发送数据量较小的分组(以下称为“keep-alive分组”)(参考非专利文献12)。此时，通信终端装置为了传输keep-alive分组，就需要定期进行连接处理，具体而言就是进行发送处理。该连接处理会使用无线接入网络中的系统资源，因而会导致无线资源以及通信节点中的处理负荷等增加的问题。此外，定期进行连接处理也会导致通信终端装置功耗的增加。本发明的目的在于提供一种能够抑制处理负荷以及功耗，确认通信终端装置状态的通信系统。解决技术问题所采用的技术方案本发明提供一种通信系统，具备与网络连接的基站装置、以及以可进行无线通信的方式与所述基站装置连接的通信终端装置，其特征在于，在所述基站装置与所述通信终端装置之间，在预先确定的监控周期对用于确认所述通信终端装置状态的监控用消息进行收发。发明效果使用本发明的通信系统，能够抑制处理负荷以及功耗，确认通信终端装置的状态。通过以下详细说明和附图，可以更加清楚本发明的目的、特征、形态以及优点。附图说明图1是表示LTE方式的通信系统的结构的说明图。图2是表示在LTE方式的通信系统中使用的无线帧的结构的说明图。图3是表示MBSFN帧的结构的说明图。图4是说明LTE方式的通信系统中使用的物理信道的说明图。图5是说明LTE方式的通信系统中使用的传输信道的说明图。图6是说明LTE方式的通信系统中使用的逻辑信道的说明图。图7是表示在3GPP中进行讨论的LTE方式的移动通信系统的整体结构的框图。图8是表示本发明所述移动终端即图7中所示移动终端71的结构的框图。图9是表示本发明所述基站即图7中所示基站72的结构的框图。图10是表示本发明所述MME即图7中所示MME部73的结构的框图。图11是表示本发明所述HeNBGW即图7中所示HeNBGW74的结构的框图。图12是表示在LTE方式的通信系统中，从移动终端(UE)进行的小区搜索到待机动作为止的概要情形的流程图。图13是表示在LTE方式的通信系统中周期性执行的TAU处理的次序的一个示例的图。图14是表示实施方式1中通信系统的次序的一个示例的图。图15是表示实施方式1的变形例2中通信系统的次序的一个示例的图。图16是表示随机接入处理的次序的一个示例的图。图17是表示实施方式1的变形例4中通信系统的次序的一个示例的图。图18是表示实施方式1的变形例4中通信系统的次序的其他示例的图。图19是表示LTE方式的通信系统中的寻呼处理的次序的一个示例的图。图20是表示LTE方式的通信系统中的寻呼处理的次序的一个示例的图。图21是表示实施方式1的变形例5中通信系统的次序的一个示例的图。图22是表示实施方式1的变形例5中通信系统的次序的一个示例的图。图23是表示实施方式1的变形例5中通信系统的次序的其他示例的图。图24是表示实施方式1的变形例5中通信系统的次序的其他示例的图。图25是表示实施方式1的变形例5中通信系统的次序的其他示例的图。图26是表示实施方式1的变形例5中通信系统的次序的其他示例的图。图27是表示用于说明实施方式2所解决课题的次序的图。图28是表示用于说明实施方式2所解决课题的次序的图。图29是表示用于说明实施方式2所解决课题的次序的图。图30是表示实施方式2中通信系统的次序的一个示例的图。图31是表示用于说明实施方式3所解决课题的次序的图。图32是表示用于说明实施方式3所解决课题的次序的图。图33是表示实施方式3中通信系统的次序的一个示例的图。图34是表示实施方式3中通信系统的次序的一个示例的图。图35是表示实施方式3中通信系统的次序的一个示例的图。图36是表示实施方式3的变形例1中通信系统的次序的一个示例的图。图37是表示实施方式3的变形例1中通信系统的次序的一个示例的图。图38是表示实施方式4中通信系统的次序的一个示例的图。图39是表示实施方式4中通信系统的次序的一个示例的图。图40是表示实施方式4的变形例1中通信系统的次序的一个示例的图。图41是表示实施方式4的变形例1中通信系统的次序的一个示例的图。图42是表示实施方式5中通信系统的次序的一个示例的图。图43是表示实施方式5中通信系统的次序的一个示例的图。图44是表示实施方式6中通信系统的次序的一个示例的图。图45是表示实施方式6中通信系统的次序的一个示例的图。图46是表示实施方式6中通信系统的次序的一个示例的图。图47是表示实施方式6中通信系统的次序的一个示例的图。图48是表示实施方式6中通信系统的次序的其他示例的图。图49是表示实施方式6中通信系统的次序的其他示例的图。图50是表示用于说明实施方式6的变形例1所解决课题的次序的图。图51是表示用于说明实施方式6的变形例1所解决课题的次序的图。图52是表示实施方式6的变形例1中通信系统的次序的一个示例的图。图53是表示实施方式6的变形例1中通信系统的次序的一个示例的图。图54是表示实施方式6的变形例1中通信系统的次序的其他示例的图。图55是表示实施方式6的变形例1中通信系统的次序的其他示例的图。图56是表示实施方式6的变形例1中通信系统的次序的其他示例的图。图57是表示用于说明实施方式7的课题的次序的图。图58是表示用于说明实施方式7的课题的次序的图。图59是表示实施方式7中通信系统的次序的一个示例的图。图60是表示实施方式7中通信系统的次序的一个示例的图。图61是表示实施方式7中通信系统的次序的一个示例的图。图62是表示实施方式7中通信系统的次序的其他示例的图。图63是表示实施方式7中通信系统的次序的其他示例的图。图64是表示实施方式7中通信系统的次序的其他示例的图。图65是表示实施方式7中通信系统的次序的其他示例的图。具体实施方式实施方式1.图7是表示在3GPP中进行讨论的LTE方式的移动通信系统的整体结构的框图。3GPP中，研究了包含CSG(ClosedSubscriberGroup)小区(E-UTRAN的Home-eNodeB(Home-eNB；HeNB)、UTRAN的Home-NB(HNB))、以及non-CSG小区(E-UTRAN的eNodeB(eNB)、UTRAN的NodeB(NB)、GERAN的BSS)的系统的整体结构，针对E-UTRAN，提出了图7所示的结构(参考非专利文献1第4.6.1章)。以下对图7进行说明。作为通信终端装置的移动终端装置(以下称“移动终端(UserEquipment：UE)”)71能够与基站装置(以下称“基站”)72进行无线通信，通过无线通信方式进行信号的收发。基站72分为作为宏小区的eNB72-1和作为本地节点的Home-eNB72-2两类。对于可以与移动终端(UE)71进行通信的范围即覆盖范围，eNB72-1具有相对较大规模的覆盖范围。Home-eNB72-2具有相对较小规模的覆盖范围。eNB72-1通过S1接口与MME、或S-GW、或包含MME以及S-GW的MME/S-GW部(以下有时称为“MME部”)73连接，在eNB72-1和MME部73之间进行控制信息的通信。对于一个eNB72-1，可以连接多个MME部73。MME部73被包含在作为核心网络的EPC中。eNB72-1之间通过X2接口连接，在eNB72-1之间进行控制信息的通信。Home-eNB72-2通过S1接口与MME部73连接，在Home-eNB72-2与MME部73之间进行控制信息的通信。对于一个MME部73，连接多个Home-eNB72-2。或者Home-eNB72-2经由HeNBGW(Home-eNBGateWay)74与MME部73连接。Home-eNB72-2与HeNBGW74通过S1接口连接，HeNBGW74与MME部73经由S1接口连接。一个或多个Home-eNB72-2与一个HeNBGW74连接，通过S1接口进行信息通信。HeNBGW74与一个或多个MME部73连接，通过S1接口进行信息通信。MME部73以及HeNBGW74是上位节点装置，对作为基站的eNB72-1以及Home-eNB72-2与移动终端(UE)71的连接进行控制。MME部73以及HeNBGW74被包含在作为核心网络的EPC中。并且在3GPP中，还对以下结构进行了探讨。支持Home-eNB72-2之间的X2接口。也就是说，Home-eNB72-2之间通过X2接口连接，在Home-eNB72-2之间进行控制信息的通信。从MME部73的角度来看，HeNBGW74就相当于Home-eNB72-2。从Home-eNB72-2的角度来看，HeNBGW74就相当于MME部73。对于Home-eNB72-2经由HeNBGW74与MME部73连接的情况以及直接与MME部73连接的情况，在这两种情况下Home-eNB72-2与MME部73之间的接口均相同，都是S1接口。HeNBGW74不支持跨多个MME部73这样的、向Home-eNB72-2移动的移动性、或者从Home-eNB72-2移动的移动性。Home-eNB72-2构成和支持唯一的小区。基站装置例如像Home-eNB72-2那样支持唯一的小区，但并不限于此，1个基站装置也可支持多个小区。1个基站装置支持多个小区时，每个小区都作为基站装置发挥功能。图8是表示本发明所述移动终端即图7中所示移动终端71的结构的框图。以下说明图8所示的移动终端71的发送处理。首先，协议处理部801发送的控制数据以及应用部802发送的用户数据被保存在发送数据缓冲部803。发送数据缓存部803中保存的数据被送到编码部804，进行纠错等编码处理。也可以存在未实施编码处理，而直接从发送数据缓冲部803向调制部805输出的数据。经过编码部804进行编码处理后的数据由调制部805进行调制处理。经过调制的数据被转换为基带信号后，输出至频率转换部806，并转换为无线发送频率。之后，由天线807将发送信号向基站72发送。移动终端71的接收处理按下述方式执行。由天线807接收来自基站72的无线信号。接收信号由频率转换部806从无线接收频率转换为基带信号，由解调部808进行解调处理。解调后的数据被送到解码部809，进行纠错等解码处理。经过解码的数据中的控制数据被送到协议处理部801，用户数据被送到应用部802。移动终端71的一系列的处理由控制部810控制。因此，虽然在图8中进行了省略，但控制部810与各部分801～809都连接。图9是表示本发明所述基站即图7中所示基站72的结构的框图。以下说明图9所示的基站72的发送处理。EPC通信部901进行基站72与EPC(MME部73、HeNBGW74等)之间的数据的收发。其他基站通信部902进行与其他基站之间的数据的收发。EPC通信部901及其他基站通信部902分别与协议处理部903进行信息的交接。来自协议处理部903的控制数据、以及来自EPC通信部901和其他基站通信部902的用户数据及控制数据保存至发送数据缓冲部904。发送数据缓存部904中保存的数据被送到编码部905，进行纠错等编码处理。也可以存在未实施编码处理，而直接从发送数据缓冲部904向调制部906输出的数据。经过编码的数据由调制部906进行调制处理。经过调制的数据被转换为基带信号后，输出至频率转换部907，并转换为无线发送频率。之后，由天线908对一个或者多个移动终端71进行发送信号的发送。基站72的接收处理按下述方式执行。来自一个或者多个移动终端71的无线信号由天线908接收。接收信号由频率转换部907从无线接收频率转换为基带信号，由解调部909进行解调处理。经过解调的数据被送到解码部910，进行纠错等解码处理。经过解码的数据中的控制数据被送到协议处理部903或者EPC通信部901、其他基站通信部902，用户数据被送到EPC通信部901和其他基站通信部902。基站72的一系列的处理由控制部911控制。因此，虽然在图9中进行了省略，但控制部911与各部分901～910都连接。当前在3GPP中讨论的Home-eNB72-2的功能如下所示(参考非专利文献1第4.6.2章)。Home-eNB72-2具有与eNB72-1相同的功能。此外，在与HeNBGW74连接的情况下，Home-eNB72-2具有发现适合的服务HeNBGW74的功能。Home-eNB72-2与1个HeNBGW74唯一连接。即，在与HeNBGW74连接的情况下，Home-eNB72-2不使用S1接口的Flex功能。Home-eNB72-2与1个HeNBGW74连接后，同时不与其他HeNBGW74或其他MME部73连接。Home-eNB72-2的TAC和PLMNID由HeNBGW74支持。若将Home-eNB72-2连接至HeNBGW74，则在“UEattachment”中的MME部73的选择由HeNBGW74进行，而不由Home-eNB72-2进行。Home-eNB72-2有可能在没有网络计划下配备。在这种情况下，Home-eNB72-2从1个地理区域移至其他地理区域。所以，这种情况下的Home-eNB72-2需要根据位置，连接至不同的HeNBGW74。图10是表示本发明所述MME的结构的框图。图10表示上述图7中所示MME部73中包含的MME73a的结构。PDNGW通信部1001进行MME73a和PDNGW之间的数据的收发。基站通信部1002进行MME73a与基站72之间的利用S1接口的数据的收发。在从PDNGW接收到的数据是用户数据的情况下，用户数据从PDNGW通信部1001经由用户层面通信部1003送到基站通信部1002，向一个或者多个基站72进行发送。在从基站72接收到的数据是用户数据的情况下，用户数据从基站通信部1002经由用户层面通信部1003送到PDNGW通信部1001，向PDNGW进行发送。在从PDNGW接收到的数据是控制数据的情况下，控制数据从PDNGW通信部1001被送至控制层面控制部1005。在从基站72接收到的数据是控制数据的情况下，控制数据从基站通信部1002被送至控制层面控制部1005。HeNBGW通信部1004在存在HeNBGW74的情况下设置，根据信息类别，进行MME73a与HeNBGW74之间的利用接口(IF)的数据的收发。从HeNBGW通信部1004接收到的控制数据，从HeNBGW通信部1004被送至控制层面控制部1005。控制层面控制部1005的处理结果经由PDNGW通信部1001发送至PDNGW。另外，由控制层面控制部1005处理的结果经由基站通信部1002利用S1接口发送至一个或者多个基站72，还经由HeNBGW通信部1004发送至一个或者多个HeNBGW74。控制层面控制部1005包含NAS安全部1005-1、SAE承载控制部1005-2、空闲状态(IdleState)移动性管理部1005-3等，对控制层面进行整体处理。NAS安全部1005-1负责NAS(Non-AccessStratum：非接入层面)消息的安全等。SAE承载控制部1005-2进行SAE(SystemArchitectureEvolution：系统架构演进)的承载的管理等。空闲状态移动性管理部1005-3进行待机状态(空闲状态(IdleState)；LTE-IDLE状态、或仅称作idle)的移动性管理、待机状态时寻呼信号的创建及控制、覆盖范围内的一个或者多个移动终端71的跟踪区域(TA)的追加、删除、更新、检索、跟踪区域列表(TAList)管理等。MME73a通过向属于注册(registered)有UE的追踪区域(跟踪区域:TrackingArea:TA)的小区发送寻呼消息，由此来履行寻呼协议。与MME73a连接的Home-eNB72-2的CSG的管理、CSG-ID的管理、还有白名单管理，也可以由空闲状态移动性管理部1005-3进行。在CSG-ID的管理中，管理(例如追加、删除、更新、检索)对应于CSG-ID的移动终端与CSG小区的关系。例如，该关系也可以是用户接入注册到某一CSG-ID的一个或者多个移动终端与属于该CSG-ID的CSG小区的关系。在白名单管理中，管理(例如追加、删除、更新、检索)移动终端与CSG-ID的关系。例如，在白名单中也可以储存某一移动终端进行了用户注册的一个或者多个CSG-ID。这些CSG相关的管理也可以由MME73a中的其他部分进行。MME73a的一系列的处理由控制部1006控制。因此，虽然在图10中进行了省略，但控制部1006与各部分1001～1005都连接。当前在3GPP中讨论的MME73a的功能如下所示(参考非专利文献1第4.6.2章)。MME73a对CSG(ClosedSubscriberGroups)的成员中的一个或者多个移动终端进行接入控制。作为选项，MME73a允许执行寻呼的最优化(Pagingoptimization)。图11是表示本发明所述HeNBGW即图7中所示HeNBGW74的结构的框图。EPC通信部1101进行HeNBGW74与MME73a之间的利用S1接口的数据的收发。基站通信部1102进行HeNBGW74与Home-eNB72-2之间的利用S1接口的数据的收发。位置处理部1103进行将经由EPC通信部1101送来的来自MME73a的数据中的注册信息等发送至多个Home-eNB72-2的处理。由位置处理部1103处理的数据被送至基站通信部1102，经由S1接口发送至一个或者多个Home-eNB72-2。不需要由位置处理部1103处理而仅通过(穿过)的数据从EPC通信部1101送至基站通信部1102，经由S1接口发送至一个或者多个Home-eNB72-2。HeNBGW74的一系列处理由控制部1104控制。因此，虽然在图11中进行了省略，但控制部1104与各部分1101～1103都连接。当前在3GPP中讨论的HeNBGW74的功能如下所示(参考非专利文献1第4.6.2章)。HeNBGW74对于S1应用进行中继。虽然是MME73a向Home-eNB72-2传输的步骤的一部分，但HeNBGW74针对与移动终端71无关的S1应用终止。在配置有HeNBGW74时，在Home-eNB72-2与HeNBGW74之间、还有HeNBGW74与MME73a之间，对与移动终端71无关的步骤进行通信。在HeNBGW74与其他节点之间不设定X2接口。作为选项，HeNBGW74允许执行寻呼的最优化(Pagingoptimization)。接下来，说明移动通信系统中小区搜索方法的一个例子。图12是表示在LTE方式的通信系统中，从移动终端(UE)进行的小区搜索到待机动作为止的概要情形的流程图。若移动终端开始小区搜索，则移动终端在步骤ST1201中，使用由周边的基站发送的第一同步信号(P-SS)、以及第二同步信号(S-SS)，取得时隙定时、帧定时的同步。P-SS与S-SS合在一起称为同步信号(SS)。同步信号(SS)被分配有同步代码，该同步代码与分配给每个小区的PCI(PhysicalCellIdentity)一一对应。PCI的数量当前研究了504种。使用该504种PCI取得同步，并且对取得了同步的小区的PCI进行检测(确定)。接下来，对于取得了同步的小区，在步骤ST1202中，检测从基站向每个小区发送的参考信号(ReferenceSignal：RS)即小区固有参考信号(Cell-specificReferenceSignal：CRS)，并对RS的接收功率(ReferenceSignalReceivedPower：RSRP)进行测定。参考信号(RS)使用与PCI一一对应的代码，通过用该代码取得相关，由此能够与其他小区分离。根据步骤ST1201中确定的PCI，通过导出该小区的RS用的代码，能够检测出RS，并测定RS的接收功率。接下来在步骤ST1203中，从步骤ST1202之前检测出的一个以上的小区中，选择RS的接收品质最佳的小区，例如RS的接收功率最高的小区，即最佳小区。接下来在步骤ST1204中，接收最佳小区的PBCH，得到广播信息即BCCH。PBCH上的BCCH映射有包含小区结构信息的MIB(MasterInformationBlock，主信息块)。所以，通过接收PBCH而得到BCCH，能够得到MIB。作为MIB的信息，例如有DL(下行链路)系统带宽(也称为发送带宽设定(transmissionbandwidthconfiguration：dl-bandwidth))、发送天线数、SFN(SystemFrameNumber，系统帧号)等。接下来在步骤ST1205中，基于MIB的小区结构信息接收该小区的DL-SCH，得到广播信息BCCH中的SIB(SystemInformationBlock，系统信息块)1。SIB1包含向该小区接入相关的信息、小区选择相关的信息、其他SIB(SIBk；k为大于等于2的整数)的调度信息。另外，SIB1包含TAC(TrackingAreaCode，跟踪区域代码)。接下来在步骤ST1206中，移动终端对在步骤ST1205接收到的SIB1的TAC、与移动终端已经保有的TA(TrackingArea)列表内的跟踪区域识别符(TrackingAreaIdentity：TAI)的TAC部分进行比较。TA(TrackingArea，跟踪区域)列表又称为TAI列表(TAIlist)。TAI是TA的识别符，由MCC(MobileCountryCode，移动国家代码)、MNC(MobileNetworkCode，移动网络代码)、TAC(TrackingAreaCode)构成。MCC为国家代码。MNC为网络代码。TAC为TA的代码编号。移动终端在步骤ST1206的比较结果为步骤ST1205中接收到的TAC与TA(TrackingArea)列表中包含的TAC相同时，在该小区进入待机动作。若经过比较，步骤ST1205中接收到的TAC未包含在TA(TrackingArea)列表中，则移动终端则通过该小区，向包含MME等的核心网络(CoreNetwork，EPC)请求用于进行TAU(TrackingAreaUpdate，跟踪区域更新)的TA(TrackingArea)的变更。核心网络基于TAU请求信号和从移动终端传送来的该移动终端的识别编号(UE-ID等)，进行TA(TrackingArea)列表的更新。核心网络向移动终端发送更新后的TA(TrackingArea)列表。移动终端基于接收到的TA(TrackingArea)列表，改写(更新)移动终端保有的TAC列表。之后，移动终端在该小区进入待机动作。在LTE、LTE-A以及UMTS(UniversalMobileTelecommunicationSystem)中，对CSG(ClosedSubscriberGroup)小区的导入进行了研究。如上所述，仅允许向注册到CSG小区的一个或者多个移动终端接入。CSG小区和注册的一个或者多个移动终端构成一个CSG。对具有这种结构的CSG标注称为CSG-ID的固有的识别编号。此外，在一个CSG中也可以有多个CSG小区。只要移动终端注册到某一个CSG小区，则能够接入至该CSG小区所属的CSG的其他CSG小区。另外，LTE以及LTE-A下的Home-eNB、UMTS下的Home-NB有时被用作CSG小区。注册到CSG小区的移动终端具有白名单。具体而言，白名单储存在SIM(SubscriberIdentityModule，用户识别模块)或USIM中。在白名单存储有移动终端注册的CSG小区的CSG信息。作为CSG信息，具体而言是指CSG-ID、TAI(TrackingAreaIdentity)、TAC等。若CSG-ID与TAC建立了对应，则哪一个都可以。另外，若CSG-ID及TAC与ECGI建立对应，则也可以是ECGI。从以上可知，没有白名单(本发明中也包含白名单为空(empty)的情况)的移动终端无法接入至CSG小区，只能接入至非CSG小区。另一方面，具有白名单的移动终端不仅能接入至注册的CSG-ID的CSG小区，还能接入至non-CSG小区。现在，要求HeNB和HNB支持各种各样的服务。例如，在某项服务中，运营商将移动终端注册到某规定的HeNB和HNB，仅允许注册的移动终端向HeNB和HNB的小区接入，通过这种方式，增大该移动终端能够使用的无线资源，实现高速通信。对于这部分服务，运营商会设定比通常高的收费。为了实现这样的服务，导入了仅有注册(加入并成为成员)的移动终端才能接入的CSG(ClosedSubscriberGroup)小区。CSG(ClosedSubscriberGroup)小区被要求在商业街、公寓、学校、公司等处大量设置。例如，要求采用如下使用方法，即，在商业街中的每个店铺、在公寓中的每间房间、在学校中的每间教室、在公司中的每个部门设置CSG小区，仅有注册到各CSG小区的用户才能使用该CSG小区。HeNB/HNB不仅用于补充宏小区的覆盖范围外的通信(区域补充型HeNB/HNB)，还希望能支持上述的各种服务(服务提供型HeNB/HNB)。因此，会产生HeNB/HNB设置在宏小区的覆盖范围内的情况。以下，针对实施方式1所解决的课题，再次进行说明。在MTC等中，为了实现低功耗，公开了将周期性执行的LAU(LocationAreaUpdate，位置区域更新)处理、RAU(RoutingAreaUpdate，路由区域更新)处理以及TAU(TrackingAreaUpdate，跟踪区域更新)的处理周期延长的措施(参考非专利文献11第6.20章)。图13是表示在LTE方式的通信系统中周期性执行的TAU处理的次序的一个示例的图(参考非专利文献13)。在步骤ST1301中，UE经由eNB，向MME通知TAU请求(TAURequest)消息。具体而言，UE使用NAS(Non-Access-Stratum)协议，通知TAU请求消息(参考非专利文献14)。在步骤ST1302中，MME利用HSS(HomeSubscriberServer，归属用户服务器)的信息，进行UE的认证(authentication)以及安全(security)控制的处理。在步骤ST1301中接收到来自UE的TAU请求消息的MME在允许TAU请求时，在步骤ST1303中，经由eNB，将TAU接受(TAUAccept)消息通知给UE。具体而言，MME使用NAS(Non-Access-Stratum)协议，通知TAU接受消息(参考非专利文献14)。在步骤ST1303中接收到MME发出的TAU接受消息的UE，在步骤ST1304中，经由eNB，将TAU完成(TAUComplete)消息通知给MME。具体而言，UE使用NAS(Non-Access-Stratum)协议，通知TAU完成消息(参考非专利文献14)。将以上步骤ST1301～步骤ST1304的处理汇总为步骤ST1305，将步骤ST1305的处理称为TAU处理(TAUProcedure)。以下以按照周期TAU定时器(periodicTAUTimer)的设定周期执行TAU的情况为例进行说明。周期TAU定时器(periodicTAUTimer)中设定了周期性执行的TAU的周期。在周期TAU定时器(periodicTAUTimer)的TAU周期1306结束后，在步骤ST1307中执行TAU处理(TAUProcedure)。在步骤ST1307中，进行与上述步骤ST1301～步骤ST1304的处理相同的处理。在周期TAU定时器(periodicTAUTimer)的TAU周期1308结束后，在步骤ST1309中执行TAU处理(TAUProcedure)。在步骤ST1309中，进行与上述步骤ST1301～步骤ST1304的处理相同的处理。以下同样，在周期TAU定时器(periodicTAUTimer)的TAU周期1310结束后，在步骤ST1311中执行TAU处理(TAUProcedure)。在周期TAU定时器(periodicTAUTimer)的TAU周期1312结束后，在步骤ST1313中执行TAU处理(TAUProcedure)。在周期TAU定时器(periodicTAUTimer)的TAU周期1314结束后，在步骤ST1315中执行TAU处理(TAUProcedure)。下面，说明为了实现MTC等的低功耗而采取措施延长周期性执行的TAU的周期的情况。以下以按照长周期TAU定时器(longperiodicTAUTimer)的设定周期执行TAU的情况为例进行说明。长周期TAU定时器(longperiodicTAUTimer)中设定了周期性执行的TAU的周期。长周期TAU定时器(longperiodicTAUTimer)中设定的TAU的周期比上述周期TAU定时器(periodicTAUTimer)中设定的TAU周期要长。在长周期TAU定时器(longperiodicTAUTimer)中的TAU周期1316结束后，在步骤ST1315中执行TAU处理(TAUProcedure)。在步骤ST1315中，进行与上述步骤ST1301～步骤ST1304的处理相同的处理。由此，通过将周期性执行的LAU处理、RAU处理、以及TAU处理的周期延长，便可以省去例如图13中的步骤ST1307、步骤ST1309、步骤ST1311、以及步骤ST1313的TAU处理(TAUProcedure)。这样，便可以实现MTC等的低功耗。然而，将周期性执行的LAU处理、RAU处理以及TAU处理的周期延长后，例如原先在图13的步骤ST1307、步骤ST1309、步骤ST1311、以及步骤ST1313的TAU处理(TAUProcedure)中所执行的基于网络的监控或移动监视的处理就不会被执行。因此，从监控和移动监视的观点来看，存在不良影响。实施方式1中提出了如下解决方法。在UE和eNB之间设置UE监控用消息。UE周期性地将UE监控用消息发送给eNB。eNB在周期内从UE接收到UE监控用消息时，判断为检测出UE。eNB在周期内未从UE接收到UE监控用消息时，判断为未检测出UE。由此，通过使用UE监控用消息，即使将TAU处理周期延长，也能以监控所需的频度进行监控。在以下说明中，有时将UE向eNB发送UE监控用消息的周期称为“UE监控周期”。此外，UE可以在定时器结束之后或以定时器结束为时机，发送UE监控用消息。该定时器有时也称为“UE监控定时器”。以下主要使用UE监控周期进行说明，但也可使用UE监控定时器。eNB接收到UE发送的UE监控用消息时，可以向UE发送送达确认信息。或者，eNB在周期内从UE接收到UE监控用消息时，可以向UE发送送达确认信息。作为送达确认信息的具体例，有RLC层中的响应消息(ACK)。送达确认信息也可以是状态PDU(StatusPDU)。eNB可以使用UE监控用消息判断UE是否存在(以下也称为“未检出判断”)。eNB在判断为UE不存在，即未检测出UE时，可执行未检出处理。作为未检出判断的具体例，揭示以下(1)～(7)的7种。(1)eNB在周期内未接收到UE监控用消息时，判断为未检测出UE。eNB在周期内接收到UE监控用消息时，判断为UE存在，即检测出UE。(2)eNB在连续多次在周期内未接收到UE监控用消息，且该次数已达预定次数时，判断为未检测出。预定次数可由静态方式决定，也可由准静态方式决定。采用准静态方式决定预定次数时，可由eNB或经由eNB将预定次数通知给UE。作为预定次数的通知方法的具体例，有以下(2-1)～(2-4)的4种。(2-1)利用广播信息进行通知。(2-2)利用专用信息进行通知。(2-3)通过TAU处理进行通知。具体而言，即利用TAU接受(TAUAccept)消息等进行通知。(2-4)通过附着处理进行通知。具体而言，利用附着接受(AttachAccept)、RRC连接重配置(RRCConnectionReconfiguration)消息等进行通知。(3)eNB在预定期间内未接收到UE监控用消息时，判断为未检测出UE。预定期间只要比UE发送UE监控用消息的周期长即可。预定期间可由静态方式决定，也可由准静态方式决定。采用准静态方式决定预定期间时，由eNB或经由eNB将预定期间通知给UE即可。预定期间通知方法的具体例与上述未检出判断的具体例(2)中预定次数的通知方法同样，因此省略说明。(4)周期性的LAU处理、RAU处理以及TAU处理可以同时使用。eNB在周期内接收到UE监控用消息时，判断为检测出UE。eNB在周期内未接收到UE监控用消息时，通知MME。MME在周期内执行了TAU处理时，判断为检测出UE。MME在周期内未执行TAU处理时，判断为未检测出UE。由此，当eNB没有接收到UE监控用消息是因为UE移动至该eNB覆盖范围之外时，MME也能进行适当的处理。即，MME可以适当地判断检测出UE。(5)eNB在周期内未接收到UE监控用消息时，可向周边eNB发送该内容的通知(以下有时称为“UE监控用消息参数通知”)。UE监控用消息参数通知可以利用X2接口或S1接口向周边eNB发送。接收到UE监控用消息参数通知的周边eNB开始从UE接收UE监控用消息。从UE接收到UE监控用消息的周边eNB向发送UE监控用消息参数通知的eNB发送收到UE监控用消息的通知。未从UE接收到UE监控用消息的周边eNB向发送UE监控用消息参数通知的eNB发送未收到UE监控用消息的通知。eNB从周边eNB接收到表示其已接收到UE监控用消息的通知时，判断为检测出UE。此外，eNB从周边eNB接收到表示其未接收到UE监控用消息的通知时，或者未从周边eNB接收到UE监控用消息时，判断为未检测出UE。作为UE监控用消息参数通知的发送方法的具体例，有以下(5-1)、(5-2)两种。(5-1)新设X2信号或X2消息。或新设S1信号或S1消息。(5-2)使用现有的X2信号或X2消息。或设置现有的S1信号或S1消息。本具体例(5-2)无需设置新的信号，这一点比具体例(5-1)更有效。利用本具体例(5-2)，可以避免通信系统的复杂化。作为映射到X2信号或S1信号的参数的具体例，有以下(5-a)～(5-d)的4种。(5-a)该移动终端的识别编号(UE-ID等)。(5-b)表示该移动终端是将UE监控用消息向eNB发送的UE的内容。也可以是表示该移动终端是MTC的内容。(5-c)UE监控周期。(5-d)上述(5-a)～(5-c)的组合。根据本具体例(5)，当eNB未接收到UE监控用消息是因为UE移动至该eNB覆盖范围之外时，也可以恰当地检测出UE。此外，在移动目的地eNB中，例如在周期等相同的条件下，可以获得UE能够继续发送UE监控用消息的效果。UE还可在移动目的地eNB与UE无需进行新的参数交换的情况下继续发送UE监控用消息，从而可获得防止控制延迟的效果。(6)在上述(1)～(5)中判断为未检测出UE后，向该UE发送寻呼通知。该UE有响应时，判断为检测出UE。该UE没有响应时，判断为未检测出UE。(7)上述(1)～(6)的组合。作为未检出处理的具体例，可举出以下(1)～(3)的3种。(1)eNB向预定的通知对象通知未检测出UE。作为预定的通知对象的具体例，有OAM(OperationAdministrationandMaintenance，运行管理和维护)、应用服务器以及MTC服务器等。(2)开始分离处理。以分离处理作为触发。(3)上述(1)、(2)的组合。作为UE向eNB通知UE监控用消息的目的的具体例，有以下(1)～(4)的4种。(1)告诉对方自己“还活着”。用于保活(keepalive)。(2)告诉对方自己的存在。(3)告诉对方自己没有宕机。告诉对方自己仍在正常动作。(4)上述(1)～(3)的组合。作为UE监控用消息的具体例，有以下(1)～(4)的4种。(1)仅Uu点的消息。Uu点是指UE和eNB、UE和HeNB、或UE和RN的接口点。本具体例(1)中，TAU从UE被通知到MME，因此是与Uu点及S1点相关的消息(参考图13的步骤ST1301、步骤ST1302、步骤ST1303、步骤ST1304)。根据本具体例(1)，UE与eNB之间的通信时间变短，可实现UE的低功耗。(2)不需要通知eNB的上位装置的消息。作为上位装置的具体例，有MME、HSS等。本具体例(2)中，与UE监控用消息不同，TAU是不需要向MME以及HSS通知的消息(参考图13的步骤ST1301、步骤ST1302)。根据本具体例(2)，UE与eNB之间的通信时间变短，可实现UE的低功耗。(3)RRC消息。本具体例(3)中，与UE监控用消息不同，TAU为NAS消息。(4)上述(1)～(3)的组合。作为将UE监控用消息设为RRC消息时的具体例，有以下(1)、(2)的两种。(1)新设RRC信号或RRC消息。(2)使用现有的RRC信号或RRC消息。本具体例(2)无需设置新的信号，这一点比具体例(1)更有效。利用本具体例(2)，可以避免通信系统的复杂化。作为新映射到RRC信号的参数的具体例，有以下(1)～(4)的4种。(1)表示是UE监控用消息的内容、“还活着”的内容、保活的内容、仍然存在的内容、没有宕机的内容、正常动作的内容等。(2)UE的识别符。作为UE的识别符，可以是移动终端识别符(UE-ID)，也可以是国际移动用户识别码(InternationalMobileSubscriberIdentity：IMSI)。(3)序列编号。可以是每次发送后递增的序列编号。也可以是用于加强安全措施的序列编号。该序列编号可以加强安全措施，例如即使取得密钥，如果该序列编号不正确，也无法解读消息等。此外，如果是在TAU处理等处理中会被初始化的序列编号，则可以防止用于发送序列编号的位数变大。(4)上述(1)～(3)的组合。接下来说明使用现有RRC信号时的具体例。此时使用测量报告(MeasurementReport)消息。作为在现有RRC信令基础上需要追加的参数的具体例，有表示是UE监控用消息的内容，“还活着”的内容、保活的内容、仍然存在的内容、没有宕机的内容、正常动作的内容等。UE监控用消息可以作为利用在TAU认证(authentication)处理中协议的密钥加密后的数据进行发送。这样，只要密钥以及用于加强安全措施的序列编号不被解读，在eNB，就可以检测有无非法UE冒充发送的UE监控用消息。考虑到通信量以及期间，密钥的修改可以适当地在TAU认证(authentication)处理时执行。另外，也可以附加消息认证代码(MessageAuthenticationCode)进行消息认证。在eNB，当检测出UE冒充时，可执行基于该服务提供商的运用政策的处理(以下称为“非法UE检出处理”)。作为非法UE检出处理的具体例，可举出以下(1)～(3)的3种。(1)eNB向预定的通知对象通知检测出非法UE。作为预定的通知对象的具体例，有OAM、应用服务器以及MTC服务器等。(2)开始分离处理。以分离处理作为触发。(3)上述(1)、(2)的组合。作为UE监控周期的设定方法的具体例，有以下(1)～(4)的4种。(1)利用广播信息进行通知。依据本具体例(1)，由于不需要对每个UE进行通知，因此可获得能够有效利用无线资源的效果。(2)利用专用信息进行通知。依据本具体例(2)，由于可以对每个UE决定设定值，因此可以构建灵活的通信系统。(3)通过TAU处理进行通知。具体而言，即利用TAU接受(TAUAccept)消息等进行通知。(4)通过附着处理进行通知。具体而言，利用附着接受(AttachAccept)消息、或RRC连接重配置(RRCConnectionReconfiguration)等进行通知。作为UE监控周期与周期性执行的TAU的周期同时结束时的动作的具体例，有以下(1)、(2)的两种。(1)执行UE监控处理以及TAU处理这两项处理。依据本具体例(1)，由于可以按每个周期决定处理，因此可获得能够避免控制复杂性的效果。(2)可以不执行UE监控处理，而执行TAU处理。依据本具体例(2)，UE可以不发送UE监控用消息。网络方的UE的监控可以通过TAU处理来执行，因此通过省略UE监控用消息的发送，可以获得UE低功耗的效果。作为UE监控周期以及周期性执行的TAU的周期的设定值的具体例，可举出周期TAU定时器(periodicTAUtimer)中设定的值。周期性执行的TAU的周期可以是UE监控周期的整数倍，也可以是整数倍的倒数(1/整数倍)。这样，UE监控周期和周期性执行的TAU的周期同时结束的机会就会增加，容易获得UE低功耗的效果。作为UE监控周期的设定值的具体例，有以下(1)～(4)的4种。(1)无线帧数(2)子帧数(3)在将UE监控周期设为周期性执行的TAU的周期的整数倍或整数倍的倒数(1/整数倍)时，将“整数”作为UE监控周期的设定值。(4)上述(1)～(3)的组合。接下来，使用图14，说明实施方式1中通信系统的次序的具体例。图14是表示实施方式1中通信系统的次序的一个示例的图。图14中所示是UE在每个UE监控周期发送UE监控用消息时的次序。图14所示的次序与图13所示的次序类似，因此相同的步骤被赋予相同的步骤编号，并省略相同的说明。在步骤ST1414中，与上述步骤ST1305同样，执行TAU处理(TAUProcedure)。在步骤ST1402中，在UE监控周期1401中，UE将UE监控用消息通知给eNB。在步骤ST1402中接收到UE监控用消息的eNB，在步骤ST1403中，将送达确认信息发送给UE。将以上步骤ST1402以及步骤ST1403的处理汇总为步骤ST1404，将步骤ST1404的处理称为UE监控处理。在步骤ST1406中，在UE监控周期1405，在UE与eNB之间执行UE监控处理。在步骤ST1408中，在UE监控周期1407，在UE与eNB之间执行UE监控处理。在步骤ST1410中，在UE监控周期1409，在UE与eNB之间执行UE监控处理。在UE监控周期1411和周期性执行的TAU的周期1412同时产生时，在步骤ST1413中，执行TAU处理(TAUProcedure)。通过以上实施方式1，可获得以下效果。通过新设置UE监控处理，即使周期性的TAU处理的周期延长，也可以通过UE监控处理进行监控。UE监控处理与TAU处理相比，在结构上可实现低功耗，因此可获得能够实现低功耗的效果。UE监控周期与TAU的周期可以单独进行设定。这样，便可获得灵活运用TAU处理的效果。通过以上方法，可以较好地实现通信终端装置的低功耗和通过网络进行的监控以及移动监视。因此，使用本发明所述通信系统，能够抑制处理负荷以及功耗，确认UE的状态。此外，在本实施方式中，UE监控用消息从UE被发送至eNB，eNB根据有无从UE接收到UE监控用消息来判断UE的状态。通过这种方式，如上所述，可以实现能够抑制处理负荷以及功耗，确认UE状态的通信系统。实施方式1变形例1.在实施方式1的变形例1中，在上述实施方式1的基础上提出了进一步的改善点。本变形例中，以不同于上述实施方式1的解决方法的部分为中心进行说明，未说明的部分与实施方式1相同。eNB从UE接收到UE监控用消息时，向UE发送对于UE监控用消息的响应消息。在本变形例1中，可对响应消息进行加密(cipher)。与实施方式1中送达确认信息是单纯的确认消息，例如ACK信息的情况相比，本变形例1发送的是经过加密的UE监控用消息的响应消息，因此可以检测出UE冒充eNB的情况。对于UE监控用消息的响应消息可以是RRC消息。作为将UE监控用消息的响应消息设为RRC消息时的具体例，有以下(1)、(2)的两种。(1)新设RRC信号或RRC消息。(2)使用现有的RRC信号或RRC消息。本具体例(2)无需设置新的信号，这一点比具体例(1)更有效。利用本具体例(2)，可以避免通信系统的复杂化。作为新映射到RRC信号的参数的具体例，有以下(1)～(4)的4种。(1)表示是UE监控用消息的响应消息的内容。(2)小区的识别符。具体而言，可以是PCI、CGI、ECGI。(3)序列编号。可以是每次发送后递增的序列编号。也可以是用于加强安全措施的序列编号。该序列编号可以加强安全措施，例如即使取得密钥，如果该序列编号不正确，也无法解读消息等。此外，如果是在TAU处理等处理中会被初始化的序列编号，则可以防止用于发送序列编号的位数变大。(4)上述(1)～(3)的组合。接下来揭示使用现有RRC信号时的具体例。使用RRC连接重配置“RRCConnectionReconfiguration”消息。作为在现有RRC信令基础上需要追加的参数的具体例，有表示是UE监控用消息的响应消息的内容。表示是UE监控用消息的响应消息的内容可以包含在现有RRC信令中设定的“理由(cause)”参数中进行通知。UE监控用消息的响应消息可以作为利用在TAU认证(authentication)处理中协议的密钥加密后的数据进行发送。这样，只要密钥以及用于加强安全措施的序列编号不被解读，在UE，就可以检测有无非法eNB冒充发送的UE监控用消息的响应消息。考虑到通信量以及期间，密钥的修改可以适当地在TAU认证(authentication)处理时执行。另外，也可以附加消息认证代码(MessageAuthenticationCode)进行消息认证。在UE，当检测出eNB冒充时，可执行基于该服务提供商的运用政策的处理(以下称为“非法eNB检出处理”)。作为非法eNB检出处理的具体例，有删除内部信息等。接下来，使用图14，说明实施方式1的变形例1中通信系统的次序的具体例。在步骤ST1402中接收到UE监控用消息的eNB，在步骤ST1403，向UE发送UE监控用消息的响应消息。依据以上实施方式1的变形例1，在实施方式1的效果之外，还可获得以下效果。可检测出UE冒充eNB的情况。实施方式1变形例2.在实施方式1的变形例2中，针对与上述实施方式1相同的课题，提出了其他的解决方法。实施方式1的变形例2中提出了如下解决方法。本变形例中，以不同于上述实施方式1的解决方法的部分为中心进行说明，未说明的部分与实施方式1相同。本变形例中，在UE和eNB之间设置UE监控用消息。eNB周期性地将UE监控用消息发送给UE。UE接收到UE监控用消息时，将送达确认用信息通知给eNB。eNB接收到送达确认用信息时，判断为检测出UE。eNB未接收到送达确认用信息时，判断为未检测出UE。由此，通过使用UE监控用消息，即使将TAU处理周期延长，也能以监控所需的频度进行监控。在以下说明中，有时将eNB向UE发送UE监控用消息的周期称为“UE监控周期”。此外，eNB可以在定时器结束之后或以定时器结束为时机，发送UE监控用消息。该定时器有时也称为“UE监控定时器”。以下主要使用UE监控周期进行说明，但也可使用UE监控定时器。作为送达确认信息的具体例，有RLC层中的响应消息(ACK)。送达确认信息也可以是状态PDU(StatusPDU)。eNB可以使用UE监控用消息的送达确认信息，判断UE是否存在(以下也称为“未检出判断”)。eNB在判断UE不存在时，即未检测出UE时，可执行未检出处理。作为未检出判断的具体例，揭示以下(1)～(6)的6种。(1)eNB在周期内未接收到送达确认信息时，判断为未检测出UE。eNB在周期内接收到送达确认信息时，判断为UE存在，即检测出UE。(2)eNB连续多次在周期内未接收到送达确认信息，且该次数已达预定次数时，判断为未检测出UE。预定次数可由静态方式决定，也可由准静态方式决定。采用准静态方式决定预定次数时，可由eNB或经由eNB将预定次数通知给UE。作为预定次数的通知方法的具体例，有以下(2-1)～(2-4)的4种。(2-1)利用广播信息进行通知。(2-2)利用专用信息进行通知。(2-3)通过TAU处理进行通知。具体而言，即利用TAU接受(TAUAccept)消息等进行通知。(2-4)通过附着处理进行通知。具体而言，利用附着接受(AttachAccept)消息、RRC连接重配置(RRCConnectionReconfiguration)消息等进行通知。(3)eNB在预定期间内未接收到送达确认信息时，判断为未检测出UE。预定期间只要比UE发送UE监控用消息的周期长即可。预定期间可由静态方式决定，也可由准静态方式决定。采用准静态方式决定预定期间时，由eNB或经由eNB将预定期间通知给UE即可。预定期间的通知方法的具体例与上述未检出判断的具体例(2)中预定次数的通知方法同样，因此省略说明。(4)周期性的LAU处理、RAU处理以及TAU处理可以同时使用。eNB在周期内接收到送达确认信息时，判断为检测出UE。eNB在周期内未接收到送达确认信息时，向MME进行通知。MME在周期内执行了TAU处理时，判断为检测出UE。MME在周期内未执行TAU处理时，判断为未检测出UE。由此，当eNB没有接收到UE监控用消息是因为UE移动至该eNB覆盖范围之外时，MME也能进行适当的处理。即，MME可以适当地判断检测出UE。(5)在上述(1)～(4)中判断为未检测出UE后，向该UE发送寻呼通知。该UE有响应时，判断为检测出UE。该UE没有响应时，判断为未检测出UE。(6)上述(1)～(5)的组合。作为未检出处理的具体例，与上述实施方式1相同，因此省略说明。此外，UE在周期内未接收到UE监控用消息时，也可将该内容通知给eNB。这样，eNB或网络方可以检测出异常。作为eNB向UE通知UE监控用消息的目的的具体例，有以下(1)～(4)的4种。(1)询问是否“还活着”。(2)询问UE是否存在。(3)询问UE是否正常动作(4)上述(1)～(3)的组合。作为UE监控用消息的具体例，有以下(1)～(3)的3种。(1)仅Uu点的消息。Uu点是指UE和eNB、UE和HeNB、或UE和RN的接口点。(2)RRC消息。本具体例(2)中，与UE监控用消息不同，TAU为NAS消息。(3)上述(1)、(2)的组合。作为将UE监控用消息设为RRC消息时的具体例，有以下(1)、(2)的两种。(1)新设RRC信号或RRC消息。(2)使用现有的RRC信号或RRC消息。本具体例(2)无需设置新的信号，这一点比具体例(1)更有效。利用本具体例(2)，可以避免通信系统的复杂化。作为新映射到RRC信号的参数的具体例，有以下(1)～(4)的4种。(1)询问是否“还活着”的内容、询问UE是否存在的内容、询问UE是否正常动作的内容等。(2)小区的识别符。具体而言，可以是PCI、CGI、ECGI。(3)序列编号。可以是每次发送后递增的序列编号。也可以是用于加强安全措施的序列编号。该序列编号可以加强安全措施，例如即使取得密钥，如果该序列编号不正确，也无法解读消息等。此外，如果是在TAU处理等处理中会被初始化的序列编号，则可以防止用于发送序列编号的位数变大。(4)上述(1)～(3)的组合。下面说明使用现有RRC信号时的具体例。使用RRC连接重配置(RRCConnectionReconfiguration)消息。作为在现有RRC信令基础上需要追加的参数的具体例，有询问是否“还活着”的内容、询问UE是否存在的内容、询问UE是否正常动作的内容等。UE监控用消息可以作为利用在TAU认证(authentication)处理中协议的密钥加密后的数据进行发送。这样，只要密钥以及用于加强安全措施的序列编号不被解读，在UE，就可以检测有无非法eNB冒充发送的UE监控用消息。考虑到通信量以及期间，密钥的修改可以适当地在TAU认证(authentication)处理时执行。另外，也可以附加消息认证代码(MessageAuthenticationCode)进行消息认证。在UE，当检测出eNB冒充时，可执行基于该服务提供商的运用政策的非法eNB检出处理。作为非法eNB检出处理的具体例，有删除内部信息等。作为UE监控周期的设定值的具体例，有以下(1)～(5)的5种。(1)无线帧数(2)子帧数(3)在UE监控周期是周期性执行的TAU的周期的整数倍或整数倍的倒数(1/整数倍)时，将“整数”作为UE监控周期的设定值。(4)与接收寻呼消息的定时相同的定时。或者，使接收寻呼消息的定时是UE监控周期的整数倍或整数倍的倒数(1/整数倍)。作为采用与接收寻呼消息的定时相同的定时的具体例，可举出在UE监控周期中使用寻呼帧(PagingFrame：PF)或寻呼时机(PagingOccasion：PO)的情况(参考非专利文献3)。因此，由于不需要重新设定UE监控周期，因此可获得能够有效运用无线资源的效果。此外，作为UE的动作，可以使接收寻呼消息的定时与接收UE监控用消息的定时一致。这样，便可以减少利用UE接通接收回路的电源的定时。因此，可以获得能够实现UE低功耗的效果。(5)上述(1)～(4)的组合。接下来，使用图15，说明实施方式1的变形例2中通信系统的次序的具体例。图15是表示实施方式1的变形例2中通信系统的次序的一个示例的图。图15中所示是eNB在每个UE监控周期发送UE监控用消息时的次序。图15所示的次序与图13所示的次序类似，因此相同的步骤被赋予相同的步骤编号，并省略相同的说明。在步骤ST1502中，在UE监控周期1501，eNB将UE监控用消息通知给UE。在步骤ST1502中接收到UE监控用消息的UE，在步骤ST1503中，将送达确认信息发送给eNB。将以上步骤ST1502以及步骤ST1503的处理汇总为步骤ST1504，并将步骤ST1504的处理称为UE监控处理。在步骤ST1506中，在UE监控周期1505，在UE与eNB之间执行UE监控处理。在步骤ST1508中，在UE监控周期1507，在UE与eNB之间执行UE监控处理。在步骤ST1510中，在UE监控周期1509，在UE与eNB之间执行UE监控处理。在UE监控周期1511和周期性运行的TAU的周期1512同时产生时，在步骤ST1513，执行TAU处理(TAUProcedure)。依据以上实施方式1的变形例2，可获得与上述实施方式1同样的效果。实施方式1变形例3.在实施方式1的变形例3中，在上述实施方式1的变形例2基础上，提出了进一步的改善点。本变形例中，以不同于上述实施方式1的变形例2的解决方法的部分为中心进行说明，未说明的部分与实施方式1的变形例2相同。UE从eNB接收到UE监控用消息时，向eNB发送对于UE监控用消息的响应消息。在本变形例中，可对响应消息进行加密(cipher)。与实施方式1的变形例2中送达确认信息是单纯的确认消息，例如ACK信息的情况相比，本变形例3发送的是UE监控用消息的响应消息，因此可以检测出eNB冒充UE的情况。UE监控用消息的响应消息可以是RRC消息。作为将UE监控用消息的响应消息设为RRC消息时的具体例，有以下(1)、(2)的两种。(1)新设RRC信号或RRC消息。(2)使用现有的RRC信号或RRC消息。本具体例(2)无需设置新的信号，这一点比具体例(1)更有效。利用本具体例(2)，可以避免通信系统的复杂化。作为新映射到RRC信号的参数的具体例，有以下(1)～(4)的4种。(1)表示是UE监控用消息的响应消息的内容。(2)UE的识别符。具体而言，可以是UE-ID、IMSI。(3)序列编号。可以是每次发送后递增的序列编号。也可以是用于加强安全措施的序列编号。该序列编号可以加强安全措施，例如即使取得密钥，如果该序列编号不正确，也无法解读消息等。此外，如果是在TAU处理等处理中会被初始化的序列编号，则可以防止用于发送序列编号的位数变大。(4)上述(1)～(3)的组合。接下来说明使用现有RRC信号时的具体例。使用RRC连接重配置完成(RRCConnectionReconfigurationComplete)消息。作为在现有RRC信令基础上需要追加的参数的具体例，有表示是UE监控用消息的响应消息的内容。表示是UE监控用消息的响应消息的内容可以包含在现有RRC信令中设定的“设定理由(EstablishmentCause)”参数中进行通知。UE监控用消息的响应消息可以作为利用在TAU认证(authentication)处理中协议的密钥加密后的数据进行发送。这样，只要密钥以及用于加强安全措施的序列编号不被解读，在eNB，就可以检测有无非法UE冒充发送的UE监控用消息的响应消息。考虑到通信量以及期间，密钥的修改可以适当地在TAU认证(authentication)处理时执行。另外，也可以附加消息认证代码(MessageAuthenticationCode)进行消息认证。在eNB，当检测出UE冒充时，可执行基于该服务提供商的运用政策的非法UE检出处理。作为非法UE检出处理的具体例，与上述实施方式1相同，因此省略说明。接下来，使用图15，说明实施方式1的变形例3中通信系统的次序的具体例。在步骤ST1502中接收到UE监控用消息的UE，在步骤ST1503，向eNB发送UE监控用消息的响应消息。依据以上实施方式1的变形例3，在实施方式1的变形例2的效果之外，还可获得以下效果。可检测出eNB冒充UE的情况。实施方式1变形例4.在实施方式1的变形例4中，针对与上述实施方式1相同的课题，提出了其他的解决方法。实施方式1的变形例4中提出了如下解决方法。本变形例中，UE会周期性地向eNB发送UE监控用消息而不建立RRC连接(RRCConnection)。换言之，UE在RRC待机状态(RRC_Idle)下，周期性地向eNB发送UE监控用消息。这样，便不需要用于建立和释放RRC连接的手续，可以获得能够实现UE低功耗的效果，以及有效运用无线资源的效果。作为不建立RRC连接而发送UE监控用消息的方法的具体例，有在随机接入(RandomAccess)处理过程中发送UE监控用消息的方法。使用此方法，无需设定新的处理，因此可获得能够避免通信系统复杂性的效果。以下，利用图16说明现有的随机接入处理(参考非专利文献1)。图16是表示随机接入处理的次序的一个示例的图。在步骤ST1601中，UE向eNB发送随机接入前导(RandomAccessPreamble)。在步骤ST1602中，eNB向UE发送随机接入响应(RandomAccessResponse)。通过PDCCH上的随机接入-无线网络临时识别符(RandomAccess-RadioNetworkTemporaryIdentity：RA-RNTI)进行寻址。通过DL-SCH，进行定时调教(TimingAlignment：TA)、初始上行调度准许、小区无线网络临时识别符(CellRadioNetworkTemporaryIdentifier：C-RNTI)的分配等。在步骤ST1603中，UE向eNB进行排程传送(ScheduledTransmission)。执行初始接入(initialaccess)。通过RRC层发送RRC连接请求(RRCConnectionRequest)。通知UE的C-RNTI。在步骤ST1604中，eNB向UE发送竞争解决(ContentionResolution)。为了使UE实现RRC连接，通过PDCCH上的C-RNTI进行寻址。作为在RACH处理过程中发送UE监控用消息的方法的具体例，有以下(1)、(2)的两种。(1)使用随机接入前导(randomaccesspreamble)。作为需要追加的参数的具体例，有表示是UE监控用消息的内容，“还活着”的内容、保活的内容、仍然存在的内容、没有宕机的内容、正常动作的内容等。(2)使用排程传送(ScheduledTransmission)消息。更具体而言，使用RRC连接请求(RRCConnectionRequest)消息(参考非专利文献2)。作为需要追加的参数的具体例，有表示是UE监控用消息的内容，“还活着”的内容、保活的内容、仍然存在的内容、没有宕机的内容、正常动作的内容等。这些内容也可以包含在上述消息中设定的“设定理由(EstablishmentCause)”的参数中进行通知。作为在RACH处理过程中发送UE监控用消息的响应消息的方法的具体例，有以下(1)、(2)的两种。(1)使用随机接入响应(RandomAccessResponse)。作为需要追加的参数的具体例，有表示是UE监控用消息的响应消息的内容。(2)使用竞争解决(ContentionResolution)消息。进而具体而言，使用RRC连接设置(RRCConnectionSetup)消息。作为需要追加的参数的具体例，有表示是UE监控用消息的响应消息的内容。接下来，使用图17，说明实施方式1的变形例4中通信系统的次序的具体例。图17是表示实施方式1的变形例4中通信系统的次序的一个示例的图。图17中所示是使用随机接入前导(RandomAccessPreamble)通知UE监控用消息时的次序。图17所示的次序与图16所示的次序类似，因此相同的步骤被赋予相同的步骤编号，并省略相同的说明。在步骤ST1701中，UE使用随机接入前导(RandomAccessPreamble)，向eNB发送UE监控用消息。在步骤ST1702中，eNB判断步骤ST1701中接收到的随机接入前导(RandomAccessPreamble)是否通知UE监控用消息。在步骤ST1702中判断为随机接入前导(RandomAccessPreamble)通知UE监控用消息时，进入步骤ST1703，判断为随机接入前导(RandomAccessPreamble)不通知UE监控用消息时，进入步骤ST1602。具体而言，当随机接入前导(RandomAccessPreamble)中未包含表示是UE监控用消息的内容时，判断为不通知UE监控用消息，进入步骤ST1602。也就是进入正常的随机接入处理。当随机接入前导(RandomAccessPreamble)中包含表示是UE监控用消息的内容时，判断为通知UE监控用消息，进入步骤ST1703。在步骤ST1703中，eNB向UE发送UE监控用消息的送达确认信息。作为送达确认信息的具体例，有RLC层中的响应消息。送达确认信息也可以是状态PDU(StatusPDU)。UE监控用消息的送达确认信息也可以利用随机接入响应(RandomAccessResponse)进行发送。然后结束处理。也就是说，不进行步骤ST1602以及步骤ST1604等中进行的用于RRC连接的处理。接下来，使用图18，说明实施方式1的变形例4中通信系统的次序的具体例。图18是表示实施方式1的变形例4中通信系统的次序的其他示例的图。图18中所示是使用RRC连接请求(RRCConnectionRequest)通知UE监控用消息时的次序。图18所示的次序与图16及图17所示的次序类似，因此相同的步骤被赋予相同的步骤编号，省略相同的说明。在步骤ST1801中，UE使用RRC连接请求(RRCConnectionRequest)，向eNB发送UE监控用消息。在步骤ST1802中，eNB判断步骤ST1801中接收到的RRC连接请求(RRCConnectionRequest)是否通知UE监控用消息。在步骤ST1802中判断为RRC连接请求(RRCConnectionRequest)通知UE监控用消息时，进入步骤ST1803，判断为RRC连接请求(RRCConnectionRequest)不通知UE监控用消息时，进入步骤ST1604。具体而言，当RRC连接请求(RRCConnectionRequest)中未包含表示是UE监控用消息的内容时，判断为不通知UE监控用消息，进入步骤ST1604。也就是进入正常的随机接入处理。当RRC连接请求(RRCConnectionRequest)中包含表示是UE监控用消息的内容时，判断为通知UE监控用消息，进入步骤ST1803。在步骤ST1803中，eNB向UE发送UE监控用消息的响应消息。UE监控用消息的响应消息也可以利用RRC连接设置(RRCConnectionSetup)进行发送。然后结束处理。也就是说，不进行步骤ST1604等中进行的用于RRC连接的处理。作为从MME向eNB通知的消息，已有表示MME过载的消息。此消息是S1接口上的“OverloadSTART”消息(参考3GPPTS36.413V10.4.0)。MME要求接收到“OverloadSTART”消息的eNB执行的动作会作为“OverloadAction”，并作为“OverloadSTART”消息的信息要素被通知(参考3GPPTS36.413V10.4.0)。“OverloadAction”中主要规定了针对RRC连接请求是否拒绝RRC连接。也就是说，在本变形例中，UE向eNB发送消息时并没有建立RRC连接(RRCConnection)，而在现有技术中，MME无法禁止这种情况下UE向eNB发送消息通知。当MME过载的时候会出现问题。作为解决上述课题的方法，在“OverloadAction”中追加参数，该参数用于禁止在未建立RRC连接(RRCConnection)时进行的消息通知。这样，当MME过载时，就可以禁止在没有建立RRC连接(RRCConnection)的情况下进行的消息通知。实施方式1的变形例4可以与上述实施方式1或实施方式1的变形例1组合使用。依据以上实施方式1的变形例4，在实施方式1的效果之外，还可获得以下效果。即，不需要用于建立和释放RRC连接的手续，可以获得能够实现UE低功耗的效果，以及有效运用无线资源的效果。实施方式1变形例5.在实施方式1的变形例5中，针对与上述实施方式1相同的课题，提出了其他的解决方法。实施方式1的变形例5中提出了如下解决方法。本变形例中，eNB会周期性地向UE发送UE监控用消息而不建立RRC连接(RRCConnection)。换言之，eNB向RRC待机状态(RRC_Idle)的UE周期性地发送UE监控用消息。这样，不需要用于建立和释放RRC连接的手续，可以获得能够实现UE低功耗的效果，以及有效运用无线资源的效果。作为不建立RRC连接而发送UE监控用消息的方法的具体例，有在寻呼处理过程中发送UE监控用消息的方法。使用此方法，无需设定新的处理，因此可获得能够避免通信系统复杂性的效果。以下，利用图19及图20说明现有的寻呼处理(参考非专利文献2)。图19及图20是表示在LTE方式的通信系统中寻呼处理的次序的一个示例的图。图19与图20在边界线BL1的位置上相连。在步骤ST1901中，MME向属于UE所处的跟踪区域中的eNB发送对象为UE的寻呼消息(Pagingmessage)。在步骤ST1902中，eNB将步骤ST1901中接收到的寻呼消息(Pagingmessage)向覆盖范围内的UE发送。在步骤ST1903中，UE判断是否是接收寻呼消息的定时。在步骤ST1903中判断为是接收寻呼消息的定时时，进入步骤ST1904，判断为不是接收寻呼消息的定时时，重复步骤ST1903的处理。在步骤ST1904中，UE在接收寻呼消息的定时接收PDCCH，然后判断PDCCH中有无寻呼无线网络临时识别符(Paging-RadioNetworkTemporaryIdentity：P-RNTI)。换而言之，UE判断P-RNTI是否受到寻址。在步骤ST1904中判断为PDCCH中有P-RNTI时，进入步骤ST1905，判断为PDCCH中没有P-RNTI时，返回步骤ST1903。在步骤ST1905中，UE判断是否是RRC_IDLE。在步骤ST1905中判断为是RRC_IDLE时，进入步骤ST1906，判断为不是RRC_IDLE时，进入图20的步骤ST1911。在步骤ST1906中，UE判断寻呼消息中的UE-ID是否与自己的UE-ID一致。寻呼消息是被映射到逻辑信道PCCH、传输信道PCH、物理信道PDSCH的消息。在步骤ST1906中判断为寻呼消息中的UE-ID与自己的UE-ID一致时，进入步骤ST1907，判断为寻呼消息中的UE-ID与自己的UE-ID不一致时，进入图20的步骤ST1911。在步骤ST1907中，UE向eNB发送RRC连接请求(RRCConnectionRequest)消息。在步骤ST1908中，eNB向UE发送RRC连接设置(RRCConnectionSetup)消息。在步骤ST1909中，UE向eNB发送RRC连接设置完成(RRCConnectionSetupComplete)消息。在步骤ST1910中，UE、eNB以及MME利用步骤ST1907～步骤ST1909中建立的RRC连接，执行服务请求(ServiceRequest)处理。在步骤ST1911中，UE判断在寻呼消息中有无表示系统信息修改的信息，即系统信息修改指标(SystemInformationModificationIndicator)。在步骤ST1911中判断为寻呼消息中有系统信息修改指标时，进入步骤ST1912，判断为寻呼消息中没有系统消息修改指标时，进入步骤ST1913。在步骤ST1912中，UE接收系统信息，进入步骤ST1913。在步骤ST1913中，UE判断寻呼消息中有无ETWS指标(EarthquakeandTsunamiWarningSystemIndicator，地震和海啸预警系统指标)。在步骤ST1913中判断为寻呼消息中有ETWS指标时，进入步骤ST1914，判断为寻呼消息中没有ETWS指标时，进入步骤ST1915。在步骤ST1914中，UE接收ETWS信息。ETWS信息映射到特有的系统信息。接收到ETWS信息后，进入步骤ST1915。在步骤ST1915中，UE判断寻呼消息中有无CMAS指标(CommercialMobileAlertServiceIndicator，商业移动预警服务指标)。在步骤ST1915中判断为寻呼消息中有CMAS指标时，进入步骤ST1916，判断为寻呼消息中没有CMAS指标时，结束处理。在步骤ST1916中，UE接收CMAS信息。CMAS信息映射到特有的系统信息。接收到CMAS信息后，结束处理。作为在寻呼处理过程中发送UE监控用消息的方法的具体例，有以下(1)～(3)的3种。(1)在PDCCH中新设用于通知有无UE监控用消息的识别符。上述识别符例如是多媒体广播/多播服务无线网络临时识别符(MultimediaBroadcast/MulticastServiceRadioNetworkTemporaryIdentity：M-RNTI)。UE在UE监控周期接收PDCCH，判断PDCCH中有无M-RNTI。换而言之，UE判断M-RNTI是否受到寻址。当判断为PDCCH中有M-RNTI时，UE判断已接收到UE监控用消息。当判断为PDCCH中没有M-RNTI时，UE判断未接收到UE监控用消息。本具体例(1)中，与下述具体例(2)、(3)不同，不需要接收寻呼消息(Pagingmessage)，因此可获得能防止控制延迟的效果。(2)将表示UE监控用消息发送的指标映射到寻呼消息(Pagingmessage)中。UE判断寻呼消息中有无表示UE监控用消息发送的指标。当判断为寻呼消息中有表示UE监控用消息发送的指标时，UE判断已接收到UE监控用消息。当判断为寻呼消息中没有表示UE监控用消息发送的指标时，UE判断未接收到UE监控用消息。本具体例(2)与上述具体例(1)不同，可以同时使用P-RNTI，减少UE对PDCCH进行解码的次数，因此可获得削减UE负荷的效果。(3)将UE监控用消息映射到寻呼消息中。作为需要追加的参数的具体例，有询问是否“还活着”的内容、询问UE是否存在的内容、询问UE是否正常动作的内容等。具体例(3)与上述具体例(1)相比，可以同时使用P-RNTI，减少UE对PDCCH进行解码的次数，因此可获得削减UE负荷的效果。作为在RACH处理过程中发送UE监控用消息的响应消息的方法的具体例，有在服务请求处理过程中进行发送的方法。作为需要追加的参数的具体例，有表示是UE监控用消息的响应消息的内容。作为在服务请求处理过程中发送的方法的具体例，有在服务请求处理过程中的RACH处理过程中进行发送的方法。作为需要追加的参数的具体例，有表示是UE监控用消息的响应消息的内容。作为在服务请求处理过程中的RACH处理过程中进行发送的方法的具体例，有以下(1)、(2)。(1)使用随机接入前导(randomaccesspreamble)。作为需要追加的参数的具体例，有表示是UE监控用消息的响应消息的内容。(2)使用排程传送(ScheduledTransmission)消息。更具体而言，使用RRC连接请求(RRCConnectionRequest)消息(参考非专利文献2)。作为需要追加的参数的具体例，有表示是UE监控用消息的响应消息的内容。表示是UE监控用消息的响应消息的内容可以包含在上述消息中设定的“设定理由(EstablishmentCause)”参数中进行通知。接下来，使用图21及图22，说明实施方式1的变形例5中通信系统的次序的具体例。图21及图22是表示实施方式1的变形例5中通信系统的次序的一个示例的图。图21与图22在边界线BL2的位置上相连。图21与图22示出通知UE监控用消息时的次序，并且PDCCH中新设了用于通知有无UE监控用消息的识别符。图21与图22所示的次序与图19及图20所示的次序类似，因此相同的步骤被赋予相同的步骤编号，并省略相同的说明。在步骤ST1904中，UE在接收寻呼消息的定时接收PDCCH，并判断PDCCH中有无P-RNTI。换而言之，UE判断P-RNTI是否受到寻址。在步骤ST1904中判断为PDCCH中有P-RNTI时，进入步骤ST1905，判断为PDCCH中没有P-RNTI时，进入步骤ST2001。在步骤ST1905中，UE判断是否是RRC_IDLE。在步骤ST1905中判断为是RRC_IDLE时，进入步骤ST1906，判断为不是RRC_IDLE时，进入步骤ST2001。在步骤ST1906中，UE判断寻呼消息中的UE-ID是否与自己的UE-ID一致。在步骤ST1906中判断为寻呼消息中的UE-ID与自己的UE-ID一致时，进入步骤ST2003，判断为寻呼消息中的UE-ID与自己的UE-ID不一致时，进入步骤ST2001。在步骤ST2001中，UE判断PDCCH中有无M-RNTI。换而言之，UE判断M-RNTI是否受到寻址。在步骤ST2001中判断为PDCCH中有M-RNTI时，进入步骤ST2002，判断为PDCCH中没有M-RNTI时，返回步骤ST1903。在步骤ST2002中，UE向MME发送UE监控用消息的响应消息。UE监控用消息的响应消息可使用随机接入前导(RandomAccessPreamble)、排程传送(ScheduledTransmission)、或RRC连接请求(RRCConnectionRequest)进行发送。然后UE进入图22的步骤ST1911。在步骤ST2003中，UE判断PDCCH中有无M-RNTI。换而言之，UE判断M-RNTI是否受到寻址。在步骤ST2003中判断为PDCCH中有M-RNTI时，进入步骤ST2004，判断为PDCCH中没有M-RNTI时，进入步骤ST1907。在步骤ST2004中，UE在RRC连接请求(RRCConnectionRequest)中追加UE监控用消息的响应消息。也可在对于寻呼的通常的响应消息中附加UE监控用消息的响应消息。也可在随机接入前导(RandomAccessPreamble)或排程传送(ScheduledTransmission)中附加UE监控用消息的响应消息。然后UE进入步骤ST1907。接下来，使用图23及图24，说明实施方式1的变形例5中通信系统的次序的具体例。图23及图24是表示实施方式1的变形例5中通信系统的次序的其他示例的图。图23与图24在边界线BL3的位置上相连。图23与图24示出通知UE监控用消息时的次序，并且，表示UE监控用消息发送的指标(以下有时称为“UE监控用指标”)被映射到寻呼消息中。图23与图24所示的次序与图19及图20所示的次序类似，因此相同的步骤被赋予相同的步骤编号，省略相同的说明。在图24的步骤ST2101中，UE判断寻呼消息中有无UE监控用指标。在步骤ST2101中判断为有UE监控用指标时，进入步骤ST2102，判断为没有UE监控用指标时，结束处理。在步骤ST2102中，UE向MME发送UE监控用消息的响应消息。UE监控用消息的响应消息可使用随机接入前导(RandomAccessPreamble)、排程传送(ScheduledTransmission)、或RRC连接请求(RRCConnectionRequest)进行发送。接下来，使用图25及图26，说明实施方式1的变形例5中通信系统的次序的具体例。图25及图26是表示实施方式1的变形例5中通信系统的次序的其他示例的图。图25与图26在边界线BL4的位置上相连。图25与图26示出通知UE监控用消息时的次序，并且UE监控用消息被映射到寻呼消息中。图25与图26所示的次序与图19及图20所示的次序类似，因此相同的步骤被赋予相同的步骤编号，省略相同的说明。在图26的步骤ST2201中，UE判断UE监控用消息是否被映射到寻呼消息中。换言之，UE判断寻呼消息中有无UE监控用消息。在步骤ST2201中判断为寻呼消息中有UE监控用消息时，进入步骤ST2102，判断为寻呼消息中没有UE监控用消息时，结束处理。实施方式1的变形例5可以与上述实施方式1的变形例2或实施方式1的变形例3组合使用。依据以上实施方式1的变形例5，在实施方式1的效果之外，还可获得以下效果。即，不需要用于建立和释放RRC连接的手续，可以获得能够实现UE低功耗的效果，以及有效运用无线资源的效果。实施方式1变形例6.在实施方式1的变形例6中，在上述实施方式1的基础上提出了进一步的改善点。本变形例中，以不同于上述实施方式1的解决方法的部分为中心进行说明，未说明的部分与实施方式1相同。本变形例中，从eNB发送到UE的送达确认信息中，含有该eNB或该eNB所属网络方的系统的相关信息。作为系统相关信息的具体例，揭示以下(1)～(4)的4种。(1)状态信息或管制信息。作为状态信息或管制信息的具体例，揭示以下(1-1)～(1-3)的3种。(1-1)表示eNB、或该eNB所属网络正常/异常的内容。(1-2)表示eNB、或该eNB所属网络拥堵/不拥堵的内容。(1-3)表示eNB、或该eNB所属网络可使用/不可使用的内容。(2)系统信息。可以是系统信息的一部分。(3)上述(1)～(2)等发生修改的日期时间。(4)上述(1)～(3)的组合。实施方式1的变形例6可以与上述实施方式1的变形例1、实施方式1的变形例2、实施方式1的变形例3、实施方式1的变形例4、或实施方式1的变形例5组合使用。将实施方式1的变形例6与实施方式1的变形例1组合时，只要在UE监控用消息的响应消息中包含该eNB或该eNB所属网络方的系统的相关信息即可。将实施方式1的变形例6与实施方式1的变形例2或实施方式1的变形例3组合时，只要在eNB发送到UE的UE监控用消息中包含该eNB或该eNB所属网络方的系统的相关信息即可。依据以上实施方式1的变形例6，在实施方式1的效果之外，还可获得以下效果。UE可在UE监控周期取得eNB或该eNB所属网络方的系统的相关信息。实施方式2.以下，针对实施方式2所解决的课题，进行说明。在目前的3GPP的E-UTRAN标准中，没有规定在RRC_CONNECTED状态下，将以UE侧为起点的RRC连接释放(RRCConnectionRelease)通知给E-UTRAN的方法。因此，当根据UE的应用的指示，进入RRC_IDLE状态后，存在UE与E-UTRAN的RRC状态不一致，E-UTRAN会一直占用不必要的系统资源的问题。图27～图29是表示用于说明实施方式2所解决课题的次序的图。图27与图28在边界线BL5的位置上相连。图28与图29在边界线BL6的位置上相连。UE具有在TCP/IP上执行的应用(以下有时称为“APP”)。在图27～图29中，在步骤ST5101，UE处于RRC_IDLE状态以及ECM(EPSConnectionManagement)_IDLE状态，在步骤ST5102，eNB相对于UE处于RRC_IDLE状态，在步骤ST5103，MME相对于UE处于ECM_IDLE状态。eNB的RRC状态表示成为eNB设想的对象UE的RRC状态(以下有时仅称为“eNB的RRC状态”)。UE的应用开始接入时，在步骤ST5104，UE的应用向UE的NAS发出接入请求(AccessRequest)。根据该接入请求，UE在步骤ST5105中启动服务请求处理A(ServiceRequestProcedureA)。步骤ST5105的服务请求处理A的具体例如下所示。在步骤ST5106中，UE的NAS向AS(AccessStratum)(RRC)发出服务请求(ServiceRequest)。在包含步骤ST5108～步骤ST5110的处理的步骤ST5107中，UE在其与eNB之间执行RRC连接设置处理(RRCConnectionSetupProcedure)。在步骤ST5108中，UE的AS(RRC)将RRC连接请求(RRCConnectionRequest)通知给eNB。在步骤ST5109，eNB将RRC连接设置(RRCConnectionSetup)通知给UE的AS(RRC)。在步骤ST5110，UE的AS(RRC)将RRC连接设置完成(RRCConnectionSetupComplete)通知给UE的AS(RRC)。由此，步骤ST5107的RRC连接设置处理完成后，UE在步骤ST5111中进入RRC_CONNECTED状态和ECM_CONNECTED状态。eNB在步骤ST5112中相对于UE进入RRC_CONNECTED状态。这样，在UE与eNB之间建立RRC连接并进入RRC_CONNECTED状态后，UE在步骤ST5113，将服务请求(ServiceRequest)消息通知给eNB。接收到服务请求消息的eNB在步骤ST5114，将服务请求消息通知给MME。在步骤ST5115，在UE、MME以及HSS之间执行认证(authentication)处理和安全(security)控制处理。MME为了将无线承载和S1承载激活，在图28的步骤ST5116中，将初始上下文设置请求(InitialContextSetupRequest)消息通知给eNB。接收到初始上下文设置请求消息的eNB在包含步骤ST5118和步骤ST5119的步骤ST5117中，在与UE之间执行无线承载建立处理(RadioBearerEstablishmentProcedure)。在步骤ST5118中，eNB将RRC连接重配置(RRCConnectionReconfiguration)消息通知给UE。在步骤ST5119中，UE将RRC连接重配置完成(RRCConnectionReconfigurationComplete)消息通知给eNB。由此，在与UE之间完成无线承载建立和S1承载设定后，eNB在步骤ST5120，将初始上下文设置完成(InitialContextSetupComplete)消息通知给MME。接收到初始上下文设置完成信息的MME在步骤ST5121，将修改承载请求(ModifyBearerRequest)消息通知给S-GW。接收到修改承载请求消息的S-GW执行包含步骤ST5123～步骤ST5125的处理的步骤ST5122的处理。具体而言，在步骤ST5123，S-GW将修改承载请求消息通知给P-GW。接收到承载请求消息的P-GW在步骤ST5124，根据承载请求消息，在与PCRF(PolicyandChargingRuleFunction，策略和计费规则功能)之间进行IP连接接入网络(IP-CAN)会话控制。具体而言，P-GW进行IP-CAN的会话修改。IP-CAN的会话修改有时称为“PCEFInitiatedIP-CANSessionModification”。在步骤ST5125中接收到修改承载响应消息的S-GW在步骤ST5126，将修改承载响应(ModifyBearerResponse)消息通知给MME。接收到修改承载响应消息的MME在步骤ST5127，相对于该UE进入ECM_CONNECTED状态。或者，也可以通过在与该UE之间完成S1连接的建立后，MME相对于该UE进入ECM_CONNECTED状态。完成与该UE之间的S1连接的建立是通过MME接收到步骤ST5120中初始上下文设置完成消息来识别。通过这些处理，在步骤ST5128，UE与P-GW之间建立EPS承载。通过根据步骤ST5105的服务请求处理来建立EPS承载，在步骤ST5129中，UE与应用服务器(APPserver)之间执行端到端(EndtoEnd)的服务，在步骤ST5130中，应用数据从UE向应用服务器进行通信。在LTE中，在RRC_CONNECTED状态下，没有规定UE以及eNB将以UE侧为起点的RRC连接释放(RRCConnectionRelease)通知给E-UTRAN的方法。因此，只要没有从网络方启动RRC连接释放(RRCConnectionRelease)，UE与eNB之间会维持RRC_CONNECTED状态，UE与MME之间将维持ECM_CONNECTED状态。网络方无法识别UE应用中有无产生数据。因此，在UE方的应用中，即使没有产生数据，网络方也无法识别该状态，因此无法立即启动RRC连接释放(RRCConnectionRelease)处理。网络方会在UE与eNB之间继续维持RRC_CONNECTED状态，在UE与MME之间继续维持ECM_CONNECTED状态。为解决该问题，网络方可以对规定期间内有无进行数据收发进行判断，在没有进行数据收发时启动S1释放处理。这样，网络方就能释放RRC连接和S1承载，在eNB之间进入RRC_IDLE状态，使UE与MME之间进入ECM_IDLE状态。然而，即使执行这种处理，例如根据UE的应用指示进入RRC_IDLE后，虽然UE会进入RRC_IDLE状态，但是E-UTRAN会维持RRC_CONNECTED状态，因此存在UE与E-UTRAN的RRC状态不一致，E-UTRAN会持续占用不必要的系统资源的问题。以下使用图27～图29说明RRC状态不一致的例子。例如，当UE的应用中没有产生数据时，在图29的步骤ST5131中，UE的NAS会将连接释放(ConnectionRelease)的指示通知给AS。在步骤ST5101中，UE进行RRC连接释放(RRCConnectionRelease)处理，并进入RRC_IDLE。在进入RRC_IDLE的同时，也可以进入ECM_IDLE。然而，由于网络方无法识别该状态，因此eNB在步骤ST5112中，将维持RRC_CONNECTED状态。eNB监控有无进行数据的收发，当规定期间内没有进行数据收发时，启动步骤ST5134的S1释放处理A(S1ReleaseProcedureA)。作为规定期间，可以设置数据监控定时器，在步骤ST5133中，eNB判断数据监控定时器是否结束。在S1释放处理A中，进行步骤ST5135～步骤ST5140的处理。在步骤ST5135中，eNB将UE上下文释放请求(UEContextReleaseRequest)通知给MME。在步骤ST5136中，MME将接入承载释放请求(ReleaseAccessBearersRequest)通知给S-GW。在步骤ST5137中，S-GW将接入承载释放响应(ReleaseAccessBearersResponse)通知给MME。在步骤ST5138中，MME将UE上下文释放命令(UEContextReleaseCommand)通知给eNB。在步骤ST5139中，eNB将RRC连接释放(RRCConnectionRelease)通知给UE。在步骤ST5140中，eNB将UE上下文释放完成(UEContextReleaseComplete)通知给MME。这样，UE的无线承载、S1承载、EPS承载就会被释放。eNB在步骤ST5141进入RRC_IDLE状态，MME在步骤ST5142进入ECM_IDLE状态。由此，当不再产生应用数据时，虽然UE在步骤ST5101进入RRC/ECM_IDLE状态，但是eNB和MME在数据监控定时器结束之前，不会启动S1释放处理，仍然是RRC_CONNECTED状态以及ECM_CONNECTED状态。因此，如步骤ST5132所示，UE与eNB、以及MME会产生状态不一致的期间。实施方式2中提出了如下解决方法。在UE与eNB之间设置用于通知UE的RRCConnection状态的消息(以下有时称为“Uukeepaliveindication”、“Uukeepaliveind”或“uu-keep-alive”)。UE周期性地向eNB发送“Uukeepaliveind”。eNB可利用“Uukeepaliveind”判断UE的RRC状态(以下有时称为“RRC状态判断”)。RRC的状态判断具体例将在后面进行说明。这样，在根据UE的应用指示，UE进入RRC_IDLE时，从UE向eNB周期性发送的“Uukeepaliveind”就会停止。因此，eNB便可判断出UE的RRC状态不是RRC_CONNECTED，即为RRC_IDLE。这样，便可以解决UE与网络(E-UTRAN)方RRC状态不一致、E-UTRAN持续占用不必要的系统资源的问题。UE向eNB发送“Uukeepaliveind”的周期也称为“Uukeepaliveind”发送周期。此外，UE可以在定时器结束之后或以定时器结束为时机，发送“Uukeepaliveind”。该定时器也称为“Uukeepaliveind”发送定时器。以下主要使用“Uukeepaliveind”发送周期进行说明，但也可使用“Uukeepaliveind”发送定时器。eNB可以接收到“Uukeepaliveind”时发送送达确认信息。或者eNB也可以在周期内接收到“Uukeepaliveind”时发送送达确认信息。作为送达确认信息的具体例，有RLC层中的响应消息(ACK)。送达确认信息也可以是状态PDU(StatusPDU)。作为UE向eNB通知“Uukeepaliveind”的目的的具体例，有以下(1)～(3)的3种。(1)告诉对方自己处于“RRC_CONNECTED”状态。(2)请求维持“RRC_CONNECTED”状态。(3)上述(1)、(2)的组合。作为RRC状态判断的具体例，可举出以下(1)～(4)的4种。(1)eNB在“Uukeepaliveind”发送周期没有接收到“Uukeepaliveind”时，判断UE为RRC_IDLE，或已从RRC_CONNECTED变为RRC_IDLE，或者未请求维持RRC_CONNECTED(以下有时统称为“判断为RRC_IDLE”)。eNB在“Uukeepaliveind”发送周期内接收到“Uukeepaliveind”时，判断UE为RRC_CONNECTED，或维持RRC_CONNECTED，或者请求维持RRC_CONNECTED(以下有时统称为“判断为RRC_CONNECTED”)。“Uukeepaliveind”发送周期的决定方法以及通知方法稍后说明。(2)eNB连续多次在“Uukeepaliveind”发送周期内未接收到“Uukeepaliveind”信息，且该次数已达预定次数时，判断为RRC_IDLE。预定次数可由静态方式决定，也可由准静态方式决定。预定次数的决定方法以及通知方法稍后说明。(3)eNB在预定期间内未接收到“Uukeepaliveind”信息时，判断为RRC_IDLE。预定期间只要比“Uukeepaliveind”的发送周期长即可。预定期间可由静态方式决定，也可由准静态方式决定。预定期间的决定方法以及通知方法稍后说明。该预定期间也可作为上述数据监控定时器。因此，在UE请求维持“RRC_CONNECTED”的期间，可以避免eNB因数据监控定时器结束而启动进入RRC_IDLE的处理。这样，便可维持UE和eNB之间的RRC_CONNECTED状态。数据监控定时器在Uu点接收到数据时启动定时器。当在Uu点接收到新的数据时，将停止数据监控定时器并复位，重新启动。作为Uu点的数据的具体例，揭示以下(3-1)～(3-3)的3种。(3-1)RRC层级的数据(3-2)NAS层级的数据(3-3)上述(3-1)、(3-2)的组合。(4)上述(1)～(3)的组合。“Uukeepaliveind”发送周期的决定主体的具体例有UE、eNB、APP服务器(应用)等。作为UE决定“Uukeepaliveind”发送周期的方法的具体例，有以下(1)～(6)的6种。(1)可依据应用来决定。UE的NAS可根据应用所请求的QoS、QCI、承载信息、会话定时器等，来决定“Uukeepaliveind”的发送周期。如果仅出于对形成通信的端到端(End-End)的应用之间的会话连接进行监视的目的，可采用定期发送小数据量分组(以下称为“keep-alive”分组)的周期，或者采用上述周期的整数倍的倒数(1/整数倍)。(2)可依据eNB所通知的DRX周期来决定。“Uukeepaliveind”发送周期可以是DRX周期的整数倍或DRX周期的整数倍的倒数(1/整数倍)。这样，便可以使RRC_CONNECTED中的UE监控PDCCH的定时即DRX周期与发送“Uukeepaliveind”的定时即“Uukeepaliveind”发送周期尽量一致，因此可以获得能够实现UE低功耗的效果。(3)可依据eNB所通知的数据监控定时器来决定。“Uukeepaliveind”发送周期可以设为比数据监控定时器短的值。这样，在UE请求维持“RRC_CONNECTED”的期间，可以避免eNB因数据监控定时器结束而启动进入RRC_IDLE的处理。(4)可根据定时提前(TimingAdvance)的有效期间来决定。“Uukeepaliveind”发送周期可以是定时提前的有效期间的整数倍或定时提前的有效期间的整数倍的倒数(1/整数倍)。这样，便可以使RRC_CONNECTED中的UE执行RACH处理的定时即定时提前的有效期间与发送“Uukeepaliveind”的定时即“Uukeepaliveind”发送周期尽量一致，因此可以获得能够实现UE低功耗的效果。(5)依据UE的负荷状况、电池剩余量来决定。负荷状况高或电池剩余量少时，延长“Uukeepaliveind”发送周期。负荷状况低或电池剩余量多时，缩短“Uukeepaliveind”发送周期或与通常相同。这样，便可针对UE负荷降低、电池剩余量少的情况采取措施。(6)上述(1)～(5)的组合。作为将UE决定的“Uukeepaliveind”发送周期通知给eNB的方法的具体例，有以下(1)、(2)的两种。(1)和“Uukeepaliveind”一同通知。可以在每次发送“Uukeepaliveind”时通知，也可在第1次发送时通知。和每次进行通知的情况相比，在第1次发送时通知可以获得削减信息量的效果。(2)在发送“Uukeepaliveind”之前通知。也可通知1次。和具体例(1)相比，可获得能够使eNB中进行用于接收“Uukeepaliveind”的准备的效果。作为具体例，揭示以下(2-1)～(2-2)的两种。(2-1)新设RRC信令或NAS信令。(2-2)使用现有的RRC信令或NAS信令。本具体例(2-2)无需设置新的信号，这一点比具体例(2-1)更有效。利用本具体例(2-2)，可以避免通信系统的复杂化。作为新映射到RRC信令或NAS信令的参数的具体例，有以下(1)～(4)的4种。(1)“Uukeepaliveind”发送周期。(2)UE的识别符。具体而言，可以是UE-ID、IMSI。(3)作为连接对象的应用服务器的信息。(4)上述(1)～(3)的组合。作为使用现有RRC信号时的具体例，可以举出使用RRC连接重配置(RRCConnectionRequest)消息的情况。作为在现有RRC信令基础上需要追加的参数的具体例，有(1)“Uukeepaliveind”发送周期、(2)作为连接对象的应用服务器的信息等。作为使用现有NAS信号时的具体例，可以举出使用服务请求(ServiceRequest)消息的情况。作为在现有NAS信令基础上需要追加的参数的具体例，有(1)“Uukeepaliveind”发送周期、(2)作为连接对象的应用服务器的信息等。作为eNB决定“Uukeepaliveind”发送周期的方法的具体例，有以下(1)～(5)的5种。(1)可依据DRX周期来决定。“Uukeepaliveind”发送周期可以是DRX周期的整数倍或DRX周期的整数倍的倒数(1/整数倍)。这样，便可以使RRC_CONNECTED中的UE监控PDCCH的定时即DRX周期与发送“Uukeepaliveind”的定时即“Uukeepaliveind”发送周期尽量一致，因此可以获得能够实现UE低功耗的效果。(2)可依据数据监控定时器或应用的会话定时器来决定。“Uukeepaliveind”发送周期可以设为比数据监控定时器短的值。这样，在UE请求维持“RRC_CONNECTED”的期间，可以避免eNB因数据监控定时器结束而启动进入RRC_IDLE的处理。(3)可根据定时提前(TimingAdvance)的有效期间来决定。“Uukeepaliveind”发送周期可以是定时提前的有效期间的整数倍或定时提前的有效期间的整数倍的倒数(1/整数倍)。这样，便可以使RRC_CONNECTED中的UE执行RACH处理的定时即定时提前的有效期间与发送“Uukeepaliveind”的定时即“Uukeepaliveind”发送周期尽量一致，因此可以获得能够实现UE低功耗的效果。(4)依据eNB的负荷状况、网络的负荷状况来决定。负荷状况高时，延长“Uukeepaliveind”发送周期或禁止“Uukeepaliveind”的发送，换言之，使“Uukeepaliveind”的发送无限大。负荷状况低时，缩短“Uukeepaliveind”发送周期或与通常相同。这样，便可以降低eNB、网络的负荷。关于网络的负荷状况，已知有从MME向eNB通知的表示MME过载的消息。也可以使用S1接口上的“OverloadSTART”消息。也可以在“OverloadSTART”中追加“Uukeepaliveind”的相关参数。也可以追加禁止“Uukeepaliveind”的参数。(5)上述(1)～(4)的组合。作为将eNB决定的“Uukeepaliveind”发送周期通知给UE的方法的具体例，有以下(1)～(6)的6种。(1)利用广播信息进行通知。(2)利用专用信息进行通知。(3)通过TAU处理进行通知。作为具体例，例如有通过“TAUAccept”等进行通知的方法。(4)通过附着处理进行通知。作为具体例，例如有通过“AttachAccept”、“RRCConnectionReconfiguration”等进行通知的方法。(5)通过RRC连接设置处理(RRCConnectionSetupProcedure)进行通知。作为具体例，例如有通过“RRCConnectionSetup”等进行通知的方法。(6)通过服务请求处理(ServiceRequestProcedure)进行通知。作为具体例，例如有通过“RRCConnectionReconfiguration”等进行通知的方法。针对APP服务器决定“Uukeepaliveind”发送周期的方法的具体例，说明如下。可依据应用来决定。可根据应用所请求的QoS、QCI、承载信息、会话定时器等，决定“Uukeepaliveind”的发送周期。如果仅出于对形成通信的端到端(End-End)的应用之间的会话连接进行监视的目的，可采用定期发送小数据量分组(以下称为“keep-alive”分组)的周期，或者采用上述周期的整数倍的倒数(1/整数倍)。将APP服务器决定的“Uukeepaliveind”发送周期通知给eNB，并且经由eNB通知给UE。预定次数的决定主体的具体例有UE、eNB、APP服务器(应用)等。作为UE决定预定次数的方法的具体例，有以下(1)～(3)的3种。(1)可依据应用来决定。UE的NAS可根据应用所请求的QoS、QCI、承载信息、会话定时器等，来决定预定次数。如果仅出于对形成通信的端到端(End-End)的应用之间的会话连接进行监视的目的，可采用定期发送小数据量分组(以下称为“keep-alive”分组)的周期，或者“UEkeepaliveind”发送周期。(2)可依据eNB所通知的数据监控定时器来决定。预定次数可采用数据监控定时器或“Uukeepaliveind”发送周期。这样，在UE请求维持“RRC_CONNECTED”的期间，可以避免eNB启动进入RRC_IDLE的处理。(3)上述(1)、(2)的组合。将UE决定的预定次数通知给eNB的方法的具体例与将UE决定的“Uukeepaliveind”发送周期通知给eNB的方法的具体例相同，因此省略说明。针对eNB决定预定次数的方法的具体例，说明如下。可依据数据监控定时器或应用的会话定时器来决定。预定次数可采用数据监控定时器或“Uukeepaliveind”发送周期。这样，在UE请求维持“RRC_CONNECTED”的期间，可以避免eNB启动进入RRC_IDLE的处理。将eNB决定的预定次数通知给UE的方法的具体例与将eNB决定的“Uukeepaliveind”发送周期通知给UE的方法的具体例相同，因此省略说明。针对APP服务器决定预定次数的方法的具体例，说明如下。可依据应用来决定。可根据应用所请求的QoS、QCI、承载信息、会话定时器等，来决定预定次数。如果仅出于对形成通信的端到端(End-End)的应用之间的会话连接进行监视的目的，可采用定期发送小数据量分组(以下称为“keep-alive”分组)的周期，或者“UEkeepaliveind”发送周期。将APP服务器决定的预订次数通知给eNB，并且经由eNB通知给UE。预定期间的决定主体的具体例有UE、eNB、APP服务器(应用)等。作为UE决定预定期间的方法的具体例，有以下(1)～(6)的6种。(1)可依据应用来决定。UE的NAS可根据应用所请求的QoS、QCI、承载信息、会话定时器等，来决定预定期间。如果仅出于对形成通信的端到端(End-End)的应用之间的会话连接进行监视的目的，可采用定期发送小数据量分组(以下称为“keep-alive”分组)的周期，或者采用上述周期的整数倍的倒数(1/整数倍)。上述数据量、数据发送周期等可以直接作为预定期间，通知给其他节点。也可以根据应用所请求的QoS、QCI、承载信息等，将UE的NAS请求RRC_CONNECTED的期间、预计RRC_CONNECTED的期间作为预定期间。(2)可依据eNB所通知的DRX周期来决定。预定期间可以是DRX周期的整数倍或DRX周期的整数倍的倒数(1/整数倍)。这样，便可以使RRC_CONNECTED中的UE监控PDCCH的定时即DRX周期与发送“Uukeepaliveind”的定时即预定期间尽量一致，因此可以获得能够实现UE低功耗的效果。(3)可依据eNB所通知的数据监控定时器来决定。预定期间可以设为比数据监控定时器短的值。这样，在UE请求维持“RRC_CONNECTED”的期间，可以避免eNB因数据监控定时器结束而启动进入RRC_IDLE的处理。(4)可根据定时提前(TimingAdvance)的有效期间来决定。预定期间可以是定时提前的有效期间的整数倍或定时提前的有效期间的整数倍的倒数(1/整数倍)。这样，便可以使RRC_CONNECTED中的UE执行RACH处理的定时即定时提前的有效期间与发送“Uukeepaliveind”的定时即预定期间尽量一致，因此可以获得能够实现UE低功耗的效果。(5)依据UE的负荷状况、电池剩余量来决定。负荷状况高或电池剩余量少时，延长预定期间。负荷状况低或电池剩余量多时，缩短预定期间或与通常相同。这样，便可针对UE负荷降低、电池剩余量少的情况采取措施。(6)上述(1)～(5)的组合。eNB决定预定期间的方法的具体例与eNB决定“Uukeepaliveind”发送周期的方法相同，因此省略说明。作为APP服务器决定预定期间的方法的具体例，说明如下。可依据应用来决定。可根据应用所请求的QoS、QCI、承载信息、会话定时器等，来决定预定期间。如果仅出于对形成通信的端到端(End-End)的应用之间的会话连接进行监视的目的，可采用定期发送小数据量分组(以下称为“keep-alive”分组)的周期，或者采用上述周期的整数倍的倒数(1/整数倍)。上述数据量、数据发送周期等可以直接作为预定期间，通知给其他节点。也可以根据应用所请求的QoS、QCI、承载信息等，将UE的NAS请求RRC_CONNECTED的期间、预计RRC_CONNECTED的期间作为预定期间。各决定主体的通知方法与“Uukeepaliveind”发送周期的决定方法以及通知方法相同，因此省略说明。eNB在RRC状态判断中判断为RRC_IDLE时，可运行IDLE迁移处理。作为IDLE迁移处理的具体例，揭示以下(1)～(3)的3种。(1)释放E-UTRAN为保持该UE的CONNECTED状态而占用的系统资源。系统资源的具体例有该UE的无线承载、S1承载、EPS承载等。作为释放方法的具体例，有由eNB启动S1释放处理(S1ReleaseProcedure)、eNB向MME发起的UE上下文释放处理、向S-GW发起的接入承载释放处理、向UE发起的RRC连接释放处理等。(2)使网络方的ECM状态迁移至ECM_IDLE。使MME的ECM状态迁移至ECM_IDLE。迁移方法的具体例与上述(1)的释放方法的具体例相同，因此省略说明。(3)使网络方的RRC状态迁移至RRC_IDLE。使eNB的RRC状态迁移至RRC_IDLE。迁移方法的具体例与上述(1)的释放方法的具体例相同，因此省略说明。作为“Uukeepaliveind”的具体例，揭示以下(1)～(4)的4种。(1)仅Uu点的消息。Uu点是指UE和eNB、UE和HeNB、或UE和RN的接口点。(2)不需要通知eNB的上位装置的消息。作为上位装置的具体例，有MME、HSS等。(3)RRC消息。(4)上述(1)～(3)的组合。作为将“Uukeepaliveind”设为RRC消息时的具体例，有以下(1)、(2)的两种。(1)新设RRC信号或RRC消息。(2)使用现有的RRC信号或RRC消息。本具体例(2)无需设置新的信号，这一点比具体例(1)更有效。利用本具体例(2)，可以避免通信系统的复杂化。作为新映射到RRC信号的参数的具体例，有以下(1)～(7)的7种。(1)表示是“Uukeepaliveind”的内容、表示是“RRC_CONNECTED”的内容、请求维持“RRC_CONNECTED”的内容等。(2)UE的识别符。具体而言，可以是UE-ID、IMSI。(3)序列编号。可以是每次发送后递增的序列编号。也可以是用于加强安全措施的序列编号。该序列编号可以加强安全措施，例如即使取得密钥，如果该序列编号不正确，也无法解读消息等。(4)“Uukeepaliveind”发送周期。接收到“Uukeepaliveind”发送周期的eNB可以将数据监控定时器设定得比“Uukeepaliveind”发送周期长。eNB可以将DRX周期设定为“Uukeepaliveind”发送周期的整数倍或它的整数倍的倒数(1/整数倍)。可以只在“Uukeepaliveind”发送周期的决定主体为UE时进行通知。(5)进行RRC状态判断时使用的预定次数。可以只在预定次数的决定主体为UE时进行通知。(6)进行RRC状态判断时使用的预定期间。可以只在预定次数的决定主体为UE时进行通知。(7)上述(1)～(6)的组合。即使不根据DRX周期决定“Uukeepaliveind”发送周期，也可以在DRX周期定时发送“Uukeepaliveind”。也可以在DRX周期的有效期间(onduration期间)发送。这样，便可以使RRC_CONNECTED中的UE监控PDCCH的定时即DRX周期与发送“Uukeepaliveind”的定时即“Uukeepaliveind”发送周期尽量一致，因此可以获得能够实现UE低功耗的效果。不根据DRX周期决定“Uukeepaliveind”发送周期时，在DRX周期定时发送“Uukeepaliveind”的方法的具体例说明如下。在紧接着“Uukeepaliveind”发送周期结束后的DRX周期定时，发送“Uukeepaliveind”。此时，eNB在紧接着“Uukeepaliveind”发送周期结束后的DRX周期定时接收“Uukeepaliveind”即可。上述实施方式2所示的“Uukeepaliveind”是用于通知连接状态的消息，因此与通常的用户数据的发送不同，可以不通过本数据发送来修改DRX长度。作为具体例，例如不会利用“Uukeepaliveind”从较长的DRX周期迁移至较短的DRX周期。图30所示的次序与图27～图29所示的次序类似，因此相同的步骤被赋予相同的步骤编号，并省略相同的说明。在步骤ST5101、步骤ST5103～步骤ST5105、步骤ST5129～5130中，UE与应用服务器之间执行端到端(EndtoEnd)的服务，应用数据从UE向应用服务器进行通信。UE在根据NAS发出的向RRC_IDLE迁移的指示，启动RRC连接释放(RRCConnectionrelease)处理之前，在步骤ST5201～步骤ST5204将“Uukeepaliveindication”通知给eNB。UE通过发送“Uukeepaliveindication”通知，向eNB表示UE目前还没向RRC_IDLE迁移，即处于RRC_CONNECTED状态。eNB通过从UE接收“Uukeepaliveindication”，了解UE目前还没向RRC_IDLE迁移，即处于RRC_CONNECTED状态。eNB根据是否能从UE接收到“Uukeepaliveindication”，来判断与eNB之间的RRC连接(RRCConnection)状态。eNB在“Uukeepaliveindication”发送周期的定时，判断是否能从UE接收到“Uukeepaliveindication”。在步骤ST5201～步骤ST5204中，UE向eNB周期性发送“Uukeepaliveindication”之后，如果UE的应用不再产生数据，则根据NAS的指示，UE在步骤ST5131中，进行RRC连接释放(RRCConnectionRelease)处理，在步骤ST5101中，进入RRC_IDLE。UE进入RRC_IDLE后，停止发送“Uukeepaliveindication”。UE停止发送“Uukeepaliveindication”后，eNB便不能在“Uukeepaliveindication”发送周期的定时接收到“Uukeepaliveindication”。即，在步骤ST5205，由于无法获得保活信息，因此保活发送周期定时器结束。由此，eNB可判断eNB与UE之间的RRC连接(RRCConnection)状态因UE向RRC_IDLE的迁移，或移动至eNB范围外等某种原因而无法维持在正常状态。在步骤ST5205中，eNB在“Uukeepaliveindication”发送周期的定时未能接收到“Uukeepaliveindication”时，启动步骤ST5134的S1释放处理A(S1ReleaseProcedureA)。在步骤ST5134中进行S1释放处理后，eNB在步骤ST5102中，相对于UE进入RRC_IDLE状态，MME在步骤ST5103中，相对于UE进入ECM_IDLE状态。在S1释放处理中，eNB与MME释放相对于UE的系统资源。依据本实施方式所提出的方法，E-UTRAN能够识别UE的RRC连接(RRCConnection)状态，因此最多在“Uukeepaliveindication”发送周期内会存在上述状态不一致的期间。因此，可以大幅减少该状态不一致所造成的影响。例如，可消除eNB为UE消耗的不必要的资源。此外，可降低发生无法向UE进行呼出的状态的发生频率。通过使“Uukeepaliveind”发送周期与DRX周期相关联，便可以使RRC_CONNECTED中的UE监控PDCCH的定时即DRX周期与发送“Uukeepaliveind”的定时即“Uukeepaliveind”发送周期尽量一致，因此可以获得能够实现UE低功耗的效果。此外，通过使“Uukeepaliveind”发送周期与数据监控定时器相关联，在UE请求维持“RRC_CONNECTED”的期间，可以避免eNB因数据监控定时器结束而启动进入RRC_IDLE的处理。这样，便可维持UE和eNB之间的RRC_CONNECTED状态。实施方式3.以下，针对实施方式3所解决的课题，进行说明。如上所述，定期发送的keep-alive分组(以下也称为“APPkeepalivepacket”)会使用无线接入网络中的系统资源，因而会导致无线资源以及通信节点中的处理负荷等增加的问题。此外，还会产生增加UE功耗的问题.以下针对如何产生这些问题进行说明。UE在应用层级的会话连接中，由于没有数据发送，因此会进行释放RRC连接(RRCconnection)和无线接入承载等的处理，进入IDLE。然而，当从应用发送了keep-alive分组时，会进行RRC连接(RRCconnection)和无线接入承载的设定处理。由此，RRC连接(RRCconnection)和无线接入承载的释放处理与设定处理重复进行，就会导致上述问题的发生。图31及图32是表示用于说明实施方式3所解决课题的次序的图。图31与图32在边界线BL7的位置上相连。图31与图32所示的次序与图27～图29所示的次序类似，因此相同的步骤被赋予相同的步骤编号，并省略相同的说明。在步骤ST5101、步骤ST5104～步骤ST5105、步骤ST5129～5130中，在UE与应用服务器之间执行端到端(EndtoEnd)的服务，应用数据从UE向应用服务器进行通信.eNB监控有无进行数据的收发，当规定期间内没有数据收发时，启动步骤ST5134的S1释放处理A(S1ReleaseProcedureA)。可设置数据监控定时器作为规定期间。在步骤ST7101中，判断数据监控定时器是否结束。通过步骤ST5134的S1释放处理，无线承载、S1承载、EPS承载被释放。UE在步骤ST5101中，进入RRC/ECM_IDLE状态。并且，eNB进入RRC_IDLE状态，MME进入ECM_IDLE状态。然后，在步骤ST7102中，产生由UE的应用定期发送的“APPkeepalivepacket”，UE响应“APPkeepalivepacket”再次启动步骤ST5105的服务请求处理A。依据服务请求处理A，UE进入RRC/ECM_CONNECTED状态。eNB相对于UE进入RRC_CONNECTED状态，MME相对于UE进入ECM_CONNECTED状态。这样，UE与应用服务器之间便可以进行通信。UE在步骤ST7103中，将“APPkeepalivepacket”发送给应用服务器。eNB对有无进行数据收发进行监控，在从UE向应用服务器发送“APPkeepalivepacket”之后，不进行数据的收发，在步骤ST7104中，数据监控定时器结束时，在步骤ST5134中，将再次启动S1释放处理A。通过该S1释放处理A，无线承载、S1承载、EPS承载被释放，在步骤ST5101中，UE将再次进入RRC/ECM_IDLE状态。并且，eNB进入RRC_IDLE状态，MME进入ECM_IDLE状态。由于在大多数情况下，“APPkeepalivepacket”发送结束后不产生应用数据，而处于定期发送“APPkeepalivepacket”的状态，因此如上所述，UE与eNB之间的RRC连接状态会频繁重复地发生迁移。由此，若RRC连接状态频繁重复地发生迁移，则由于RRC连接状态迁移，信令量就会增大，因此会产生无线接入网络中的系统资源增大以及UE功耗增加的问题。此外，在UE，RRC的状态与ECM的状态会联动地发生迁移。ECM_CONNECTED状态的UE在RRC连接(RRCConnection)被释放时，就会进入ECM_IDLE状态。RRC连接被释放后，就成为RRC_IDLE状态。因此，通过RRC连接的释放，就会从RRC_CONNECTED迁移到RRC_IDLE，并且与之联动地从ECM_CONNECTED迁移到ECM_IDLE(参考非专利文献13第4.6.4章)。在网络，RRC的状态与ECM的状态会联动地发生迁移。当作为对象的UE的RRC状态进入RRC_IDLE时，ECM_CONNECTED状态下的eNB，启动S1释放处理(S1ReleaseProcedure)。S1连接被释放后，从ECM_CONNECTED迁移到ECM_IDLE。因此，，S1连接与向RRC_IDLE的迁移联动地被释放，从而从ECM_CONNECTED迁移到ECM_IDLE(参考非专利文献13第4.6.4章)。如上所述，由于RRC连接状态的迁移频繁重复地进行，因此ECM状态的迁移也会频繁重复地进行。这样，例如S1承载的建立与释放的控制处理会频繁进行，因此会产生信令量增大、无线接入网络中的系统资源增大的问题。实施方式3中提出了如下解决方法。使Uu点的RRC状态与APP的会话连接状态一致，以解决上述问题。在eNB，通过识别该UE的RRC状态，从而识别APP会话的连接状态，向网络方实体例如S-GW通知该信息。在接到通知的网络方实体中，例如在S-GW中，进行模拟的keep-alive分组(以下也称为“模拟APPkeepalivepacket”或“本地APPkeepalivepacket”)的发送控制。eNB中对UE进行的RRC状态的识别依据现行的3GPP标准进行。对于应用所请求发送的keep-alive分组，UE不将其向Uu点上发送。对是否执行使Uu点的RRC状态与APP会话的连接状态一致的方法进行判断的判断主体的具体例如下所示。(1)UE。(2)网络方。具体而言即S-GW或P-GW。作为判断的具体例，可举出以下(1A)、(2A)两种。(1A)揭示判断主体为UE的情况。UE根据提出接入请求的应用进行判断。判断是否是请求发送keep-alive分组的应用。UE经过上述判断后，判断是请求发送keep-alive分组的应用时，在UE(NAS)中，将针对本地APPkeepalivepacket发送的Ack(本地Ack)通知给UE的应用。并且，UE将上述判断结果(以下有时也称为“APPkeepalive信息”)通知给网络方。作为网络方的具体例，有将本地APPkeepalivepacket发送给应用服务器的实体。例如，S-GW等。作为具体的通知方法，例如UE将本地APPkeepalivepacket的发送请求通知给MME。接收到本地APPkeepalivepacket发送请求的MME，将本地APPkeepalivepacket的发送请求通知给S-GW。作为UE将本地APPkeepalivepacket的发送请求通知给MME的方法的具体例，有以下(1)、(2)的两种。(1)新设NAS信号。(2)使用现有的NAS信号。本具体例(2)无需设置新的信号，这一点比具体例(1)更有效。利用本具体例(2)，可以避免通信系统的复杂化。作为新映射到NAS信号的参数的具体例，有以下(1)～(5)的5种。(1)表示是本地APPkeepalivepacket发送请求的内容、是用于进行设定以使得Uu点的RRC状态与APP的会话连接状态一致的信息等。以下有时也称为“APPkeepalive信息”。(2)UE的识别符。具体而言，可以是UE-ID、IMSI。(3)作为连接对象的应用服务器的信息。(4)keep-alive分组的发送周期。(5)上述(1)～(4)的组合。作为使用现有NAS信号时的具体例，可以举出使用服务请求(ServiceRequest)消息的情况。作为需要追加到现有NAS信令的参数的具体例，有以下(1)～(3)的3种。(1)表示是本地APPkeepalivepacket发送请求的内容等、是用于进行设定以使得Uu点的RRC状态与APP的会话连接状态一致的信息等。(2)作为连接对象的应用服务器的信息。(3)keep-alive分组的发送周期。作为MME将本地APPkeepalivepacket的发送请求通知给S-GW的方法的具体例，有以下(1)、(2)的两种。(1)新设S11信号。(2)使用现有的S11信号。本具体例(2)无需设置新的信号，这一点比具体例(1)更有效。利用本具体例(2)，可以避免通信系统的复杂化。作为新映射到S11信号的参数的具体例，有以下(1)～(5)的5种。(1)表示是本地APPkeepalivepacket发送请求的内容等、是用于进行设定以使得Uu点的RRC状态与APP的会话连接状态一致的信息等。(2)UE的识别符。具体而言，可以是UE-ID、IMSI。(3)作为连接对象的应用服务器的信息。(4)keep-alive分组的发送周期。接收到keep-alive分组的发送周期的S-GW可将本地APPkeepalivepacket的发送周期设定为与keep-alive分组的发送周期相同。(5)上述(1)～(4)的组合。作为使用现有S11信号时的具体例，可以举出使用修改承载请求(ModifyBearerRequest)消息的情况。作为需要追加到现有S11信令的参数的具体例，有以下(1)～(3)的3种。(1)表示是本地APPkeepalivepacket发送请求的内容等、是用于进行设定以使得Uu点的RRC状态与APP的会话连接状态一致的信息等。(2)作为连接对象的应用服务器的信息。(3)keep-alive分组的发送周期等。接收到keep-alive分组的发送周期的S-GW可将本地APPkeepalivepacket的发送周期设定为与keep-alive分组的发送周期相同。(2A)揭示判断主体为网络方，例如为S-GW的情况。S-GW根据提出接入请求的应用进行判断。判断是否是请求发送keep-alive分组的应用。S-GW经过上述判断后，判断是请求发送keep-alive分组的应用时，将本地APPkeepalivepacket发送给应用服务器。并且，S-GW将上述判断结果(以下有时也称为“APPkeepalive信息”)通知给UE方。作为通知方法的具体例，例如S-GW将针对本地APPkeepalivepacket发送的Ack(本地Ack)的发送请求通知给MME。MME接收到针对本地APPkeepalivepacket发送的Ack(本地Ack)的发送请求后，经由eNB，将针对本地APPkeepalivepacket发送的Ack(本地Ack)的发送请求通知给UE。作为S-GW将针对本地APPkeepalivepacket发送的Ack(本地Ack)的发送请求通知给MME的方法的具体例，有以下(1)、(2)的两种。(1)新设S11信号。(2)使用现有的S11信号。本具体例(2)无需设置新的信号，这一点比具体例(1)更有效。利用本具体例(2)，可以避免通信系统的复杂化。作为新映射到S11信号的参数的具体例，有以下(1)～(5)的5种。(1)表示是针对本地APPkeepalivepacket发送的Ack(本地Ack)的发送请求的内容等、是用于进行设定以使得Uu点的RRC状态与APP的会话连接状态一致的信息等。(2)UE的识别符。具体而言，可以是UE-ID、IMSI。(3)作为连接对象的应用服务器的信息。(4)本地APPkeepalivepacket发送周期。(5)上述(1)～(4)的组合。作为使用现有S11信号时的具体例，可以举出使用修改承载响应(ModifyBearerResponse)消息的情况。作为需要追加到现有S11信令的参数的具体例，有以下(1)～(3)的3种。(1)表示是针对本地APPkeepalivepacket发送的Ack(本地Ack)的发送请求的内容等、是用于进行设定以使得Uu点的RRC状态与APP的会话连接状态一致的信息等。(2)作为连接对象的应用服务器的信息。(3)本地APPkeepalivepacket的发送周期。作为MME将针对本地APPkeepalivepacket发送的Ack(本地Ack)的请求通知给UE的方法的具体例，有以下(1)、(2)的两种。(1)新设信号。(2)使用现有的信号。本具体例(2)无需设置新的信号，这一点比具体例(1)更有效。利用本具体例(2)，可以避免通信系统的复杂化。作为新映射到NAS信号的参数的具体例，有以下(1)～(5)的5种。(1)表示是针对本地APPkeepalivepacket发送的Ack(本地Ack)的发送请求的内容、是用于进行设定以使得Uu点的RRC状态与APP的会话连接状态一致的信息等。以下有时也称为“APPkeepalive信息”。(2)UE的识别符。具体而言，可以是UE-ID、IMSI。(3)作为连接对象的应用服务器的信息。(4)本地APPkeepalivepacket发送周期。(5)上述(1)～(4)的组合。接着，作为使用现有信号时的具体例，使用服务请求(ServiceRequest)处理。具体而言，有服务请求处理过程中的初始上下文设置请求(InitialContextSetupRequest)、RRC连接重配置(RRCConnectionReconfiguration)等。作为需要追加到现有信令的参数的具体例，有以下(1)～(3)的3种。(1)表示是针对本地APPkeepalivepacket发送的Ack(本地Ack)的发送请求的内容等、是用于进行设定以使得Uu点的RRC状态与APP的会话连接状态一致的信息等。(2)作为连接对象的应用服务器的信息。(3)本地APPkeepalivepacket的发送周期。图33～图35是表示实施方式3中通信系统的次序的一个示例的图。图33与图34在边界线BL8的位置上相连。图34与图35在边界线BL9的位置上相连。图33～图35所示的次序与图27～图29所示的次序类似，因此相同的步骤被赋予相同的步骤编号，并省略相同的说明。UE具有在TCP/IP上执行的应用。在图33～图35中，在步骤ST5101，UE处于RRC_IDLE状态，在步骤ST5102，eNB相对于UE处于RRC_IDLE状态，在步骤ST5103，MME相对于UE处于ECM_IDLE状态。UE的应用开始接入时，在步骤ST5104，UE的应用向UE的NAS发出接入请求(AccessRequest)。根据该接入请求，UE在步骤ST7201启动服务请求处理B(ServiceRequestProcedureB)。步骤ST7201的服务请求处理B只需部分修改图27中步骤ST5105的服务请求处理A即可。以下针对修改部分进行说明。在步骤ST7202中，由UE的NAS向AS通知的服务请求消息中包含“APPkeepalive信息”。“APPkeepalive信息”是用于进行设定以使得Uu点的RRC状态与APP的会话连接状态一致的信息。例如可以是表示是否设定的信息，也可以仅在设定时将该信息包含在消息中。UE在步骤ST7203中，使服务请求消息中包含“APPkeepalive信息”并向eNB进行通知。eNB在步骤ST7203中接收到“APPkeepalive信息”后，使步骤ST7204的服务请求消息中包含“APPkeepalive信息”并向MME进行通知。MME接收到“APPkeepalive信息”后，使步骤ST7205的修改承载请求消息中包含“APPkeepalive信息”并向S-GW进行通知。通过这种方式，便可以向网络方实体即S-GW通知是否进行设定以使得Uu点的RRC状态与APP会话的连接状态一致。因此，S-GW便可以根据是否要进行设定以使得Uu点的RRC状态与APP会话的连接状态一致而采取相应的处理。图33～图35所示例中，作为步骤ST7202、步骤ST7203、步骤ST7204、步骤ST7205的“APPkeepalive信息”，示出设定为使得Uu点的RRC状态与APP会话的连接状态一致的情况。对于应用所请求发送的keep-alive分组，UE不将其向Uu点上发送。在图35的步骤ST7206中，UE判断应用的APPkeepalivepacket发送周期定时器(以下有时称为“保活发送周期定时器”)是否结束。当判断保活发送周期定时器结束时，在步骤ST7207中，向NAS发送“APPkeepalivepacket”。由于产生了“APPkeepalivepacket”，UE不向Uu点上发送“APPkeepalivepacket”，因此不启动服务请求处理。此外，在UE，NAS从应用接收到“APPkeepalivepacket”后，在步骤ST7209中，可以将响应消息通知给应用。该响应消息称为本地响应。UE的NAS对RRC/ECM的状态进行识别，在识别为RRC/ECM_CONNECTED状态时，将Ack(本地Ack)通知给应用。在识别为RRC/ECM_IDLE状态时，将Nack(本地Nack)通知给应用。UE的应用接收到本地Ack后，判断RRC/ECM处于连接状态，并继续发送“APPkeepalivepacket”，保持会话连接状态。UE的应用接收到本地Nack后，判断RRC/ECM处于未连接状态，停止发送“APPkeepalivepacket”。也可切断会话连接。在步骤ST7209中从NAS接收到本地Ack的应用，在步骤ST7211中判断保活发送周期定时器已结束时，在步骤ST7213中继续发送“APPkeepalivepacket”。由于UE的RRC/ECM处于连接状态，因此在步骤ST7215中，NAS将本地Ack通知给应用。另一方面，网络方实体例如S-GW，进行模拟的keep-alive分组(以下也称为“本地APPkeepalivepacket”)的发送控制。S-GW接收到设定为使Uu点的RRC状态与APP会话连接状态一致的“APPkeepalive信息”后，决定创建本地APPkeepalivepacket，并向应用服务器发送。S-GW定期或周期性创建本地APPkeepalivepacket，只要设立了EPS承载，就定期或周期性地创建本地APPkeepalivepacket并向应用服务器发送。在步骤ST7205中，S-GW接收到设定为使Uu点的RRC状态与APP会话连接状态一致的“APPkeepalive信息”后，在步骤ST7208中，判断本地APPkeepalivepacket发送周期定时器(以下有时称为“本地保活发送周期定时器”)是否结束。S-GW判断本地保活发送周期定时器结束时，在步骤ST7210中，向应用服务器发送本地(Local)APPkeepalivepacket。S-GW判断是否设立了EPS承载，当判断为已设立时，继续在步骤ST7212中判断本地保活发送周期定时器是否结束。S-GW在判断为本地保活发送周期定时器结束时，在步骤ST7214中，向应用服务器发送本地(Local)APPkeepalivepacket。这里，接收到本地APPkeepalivepacket的APP服务器可以向S-GW发送响应信号(Ack)。响应信号可以是响应消息。在应用方，当与该UE的会话结束时，APP服务器也可不向S-GW发送上述响应信号。S-GW从APP服务器接收到本地APPkeepalivepacket的响应信号时，可判断与该UE之间的会话仍在继续。另一方面，从APP服务器没有接收到本地APPkeepalivepacket的响应信号时，S-GW可判断与该UE之间的会话已经停止。当判断为与该UE之间的会话已经结束时，S-GW可启动EPS的释放处理。在步骤ST7216中，eNB对有无数据收发进行监控。当规定期间内没有进行数据收发时，将启动步骤ST5134的S1释放处理A。在进行了使Uu点的RRC状态与APP的会话连接状态一致的设定时，在步骤ST7216，将数据监控定时器设定为长期间。可以设定为比图31及图32中步骤ST7101、步骤ST7104以及步骤ST7118所示的数据监控定时器长的期间。通过步骤ST5134的S1释放处理A，无线承载、S1承载、EPS承载被释放。在步骤ST5101中，UE进入RRC/ECM_IDLE状态。在步骤ST5102中，eNB相对于UE进入RRC_IDLE状态。在步骤ST5103中，MME相对于UE进入ECM_IDLE状态。UE也可以监控是否进行了数据收发。在规定期间没有进行数据收发时，UE的NAS即使从应用收到了“APPkeepalivepacket”，也可不将本地响应通知给应用。这样，UE方的应用就会识别出会话已经结束。此外，在规定期间没有进行数据收发时，UE向MME通知停止发送本地APPkeepalivepacket的请求。接收到本地APPkeepalivepacket停止发送请求的MME，可将本地APPkeepalivepacket的停止发送请求通知给S-GW。接收到本地APPkeepalivepacket停止发送请求的S-GW，停止发送本地APPkeepalivepacket。这样，也能在APP服务器方的应用中结束与该UE之间的会话。在步骤ST5101中，UE识别出进入RRC/ECM_IDLE状态后，在步骤ST7218中，将已进入RRC/ECM_IDLE状态的情况通知给应用。该消息称为本地释放。应用接收到本地释放后，判断RRC/ECM处于未连接状态，并停止发送“APPkeepalivepacket”。也可切断会话连接。另一方面，S-GW识别出EPS承载已经释放后，在步骤ST7217中，停止创建本地APPkeepalivepacket(以下有时称为“本地保活分组”)。在步骤ST7219中，S-GW将应用会话的释放(LocalAPPSessionRelease)消息通知给应用服务器。应用会话的释放消息中可以含有停止创建本地APPkeepalivepacket的理由的信息。此外，停止创建本地APPkeepalivepacket时的应用会话释放消息可以新设。停止创建本地APPkeepalivepacket时的应用会话释放消息称为本地应用会话释放消息。接收到本地应用会话释放消息的应用服务器判断EPS承载处于未设立的状态，可切断会话连接。也可重新启动会话。通过上述方法，便可使Uu点的RRC状态与APP的会话连接状态一致。这样，在Uu点，便无需因为应用产生了keep-alive分组而适当地改变RRC和RAB的状态。通过在步骤ST7216将数据监控定时器设定为长期间，可减少启动步骤ST5134中S1释放处理A的频率。因此，便可减少释放无线承载、S1承载、EPS承载的频率，减少用于使RRC/ECM状态进行迁移以发送来自应用的“APPkeepalivepacket”的信令。因此，可以抑制由于应用产生keepalivepacket而导致不需要的信令增加的情况，减轻对系统资源的影响。实施方式3变形例1.实施方式3的变形例1所要解决的课题与上述实施方式3的课题相同，说明如下。实施方式3中，使用UE与eNB的RRC连接(RRCConnection)状态，因此可能会产生上述实施方式2中提出的UE与eNB之间状态不一致的问题。为解决上述课题，在实施方式3的变形例1中，将上述实施方式2的解决方案用于实施方式3。图36及图37是表示实施方式3的变形例1中通信系统的次序的一个示例的图。图36与图37在边界线BL10的位置上相连。图36与图37所示的次序与图33～图35所示的次序类似，因此相同的步骤被赋予相同的步骤编号，省略相同的说明。在步骤ST5101～步骤ST5104、步骤ST7201、步骤ST5129～5130中，UE与应用服务器之间执行端到端(EndtoEnd)的服务，应用数据从UE向应用服务器进行通信.本变形例中，使用上述实施方式3中提出的方法，因此作为服务请求处理，在步骤ST7201中，进行使用“APPkeepalive信息”的服务请求处理B。图36及图37中，作为“APPkeepalive信息”，示出进行设定以使得Uu点的RRC状态与APP会话的连接状态一致时的次序。如上述实施方式3所述，对于应用所请求发送的keep-alive分组，UE不将其向Uu点上发送。此外，网络方实体例如S-GW，进行本地APPkeepalivepacket的发送控制。因此，进行步骤ST7206～步骤ST7215的处理。在上述实施方式3中，在进行步骤ST5130的数据发送后，在步骤ST7216中，在数据监控定时器结束，步骤ST5134进行S1释放处理之前，会维持UE与eNB之间的RRC连接(RRCConnection)状态。在此状态下，有时会因为UE移动到eNB范围外，或UE的接收质量恶化等某种原因，不能正常维持和eNB之间的RRC连接(RRCConnection)状态。这种情况下，UE的RRC状态会迁移到RRC_IDLE，而eNB会维持RRC_CONNECTED状态。因此，会产生UE与eNB之间状态不一致的问题。并且，在UE与eNB之间出现状态不一致的情况时，识别到变为RRC_IDLE状态的UE将已进入RRC_IDLE状态的情况通知给应用。应用接收到该通知后，判断RRC处于未连接状态，停止发送“APPkeepalivepacket”，结束会话。这样，在UE的应用中，会话就会结束。然而，由于eNB仍然维持着RRC_CONNECTED状态，因此MME会维持ECM_CONNECTED状态，S-GW会继续创建本地keepalivepacket并发送给应用服务器。因此，在应用服务器，将识别为会话仍在连接中。像这样，UE方的应用与应用服务器也会出现状态不一致的现象。在上述实施方式2中，为改善这种状态不一致的问题，提出了以下方法，即在Uu点，设置用于通知UE处于RRC连接(RRCConnection)状态的消息，UE在RRC_CONNECTED状态下，定期或周期性发送“Uukeepaliveindication”。本变形例中，使用该实施形态2的解决方案。在图36和图37所示例中，进行了步骤ST5130的数据发送后，处于RRC_CONNECTED状态的UE如步骤ST7301～步骤ST7305所示，周期性地将“Uukeepaliveindication”通知给eNB。UE通过发送“Uukeepaliveindication”通知，向eNB表示UE目前还没向RRC_IDLE迁移，即处于RRC_CONNECTED状态。eNB通过从UE接收“Uukeepaliveindication”，了解到UE目前还没向RRC_IDLE迁移，即处于RRC_CONNECTED状态。eNB根据是否能从UE接收到“Uukeepaliveindication”，来判断与eNB之间的RRC连接(RRCConnection)状态。eNB在“Uukeepaliveindication”发送周期的定时，判断是否能从UE接收到“Uukeepaliveindication”。在步骤ST7304中，UE会向eNB发送“Uukeepaliveindication”，但有时会因为某些原因，UE与eNB之间的RRC连接(RRCConnection)状态不能正常维持，“Uukeepaliveindication”未送达eNB的情况。此时，在步骤ST5205，eNB便不能在“Uukeepaliveindication”发送周期的定时接收到“Uukeepaliveindication”。因此，eNB对UE由于某些原因而未能正常维持eNB与UE之间的RRC连接(RRCConnection)中的状态的情况进行识别，由此来启动步骤ST5134的S1释放处理A。步骤ST5134中进行了S1释放处理后，UE在步骤ST5101中，进入RRC_IDLE状态。eNB在步骤ST5102中，相对于UE进入RRC_IDLE状态。MME在步骤ST5103中，相对于UE进入ECM_IDLE状态。在S1释放处理中，eNB与MME释放相对于UE的系统资源。在步骤ST5101中，UE识别出进入RRC/ECM_IDLE状态后，在步骤ST7218中，将已进入RRC/ECM_IDLE状态的情况通知给应用。应用接收到本地释放后，判断RRC/ECM处于未连接状态，停止发送“APPkeepalivepacket”。也可切断会话连接。识别出在步骤ST5134中进行S1释放处理，EPS承载被释放的S-GW，在步骤ST7217中，停止创建本地APPkeepalivepacket。在步骤ST7219中，S-GW将本地应用会话的释放消息通知给应用服务器。接收到本地应用会话释放消息的应用服务器判断EPS承载处于未设立的状态，可切断会话连接。通过本实施方式提出的方法，E-UTRAN可识别UE的RRC连接(RRCConnection)状态，因此可以消除上述实施方式3的方法中产生的上述状态不一致的期间。因此，可以大幅减少该状态不一致所造成的影响。例如，可消除eNB为UE消耗的不必要的资源。此外，可降低发生无法向UE进行呼出的状态的发生频率。在图36和图37所示的例中，UE通过步骤ST5134的S1释放处理，在步骤ST5101中，进入RRC/ECM_IDLE状态。其他方法还有，处于RRC_CONNECTED状态的UE由于接收质量恶化等某种原因进入RRC_IDLE状态时，判断为UE已进入RRC_IDLE状态，并将本地释放消息通知给UE的应用。UE在进入RRC_IDLE状态时，可同时判断已进入ECM_IDLE状态。此时，在步骤ST5134的S1释放处理之前，UE进入RRC/ECM_IDLE状态，UE的应用停止发送“APPkeepalivepacket”，或切断会话连接。这种情况下，上述实施方式3的方法中会产生的所述状态不一致的期间也最多出现在“Uukeepaliveindication”发送周期内。因此，可以大幅减少该状态不一致所造成的影响。例如，可减少eNB为UE而消耗的不必要的资源，降低出现无法向UE进行呼出的状态的发生频率。实施方式4.实施方式4所要解决的课题与上述实施方式3的课题相同，说明如下。上述实施方式3中，由于希望使RRC连接(RRCConnection)的状态与应用层级的会话状态一致，因此在应用层级的会话连接过程中，需要维持RRC连接(RRCConnection)。这虽然可以有效避免keep-alive分组造成的影响，但作为代价，就需要使用用于维持RRC连接(RRCConnection)的无线资源。实施方式4中提出了如下解决方法。为解决上述问题，设置用于在RRC_IDLE状态下通知应用会话连接状态的Uu点消息(uukeepalivepacket)。UE在迁移至RRC_IDLE的状态下，定期或周期性发送“uukeepalivepacket”。eNB根据从UE接收“uukeepalivepacket”的状况以及相对于UE的RRC状态，识别UE的应用的会话连接状态，并将该信息通知给某一网络装置，例如S-GW。接收到通知的上述网络装置即S-GW中，进行本地APPkeepalivepacket的发送控制。仅在UE处于RRC_IDLE时发送“uukeepalivepacket”。发送“uukeepalivepacket”不改变RRC状态。即，IDLE时，仅通知而不开启RRC连接。例如，使用RACH进行通知。与上述实施方式3同样，对于应用所请求发送的keep-alive分组，UE不将其向Uu点上发送。图38及图39是表示实施方式4中通信系统的次序的一个示例的图。图38与图39在边界线BL11的位置上相连。图38与图39所示的次序与图33～图35所示的次序类似，因此相同的步骤被赋予相同的步骤编号，并省略相同的说明。在步骤ST5101～步骤ST5104、步骤ST7201、步骤ST5129～5130中，在UE与应用服务器之间执行端到端(EndtoEnd)的服务，应用数据从UE向应用服务器进行通信。本变形例中，使用上述实施方式3中提出的方法，因此作为服务请求处理，在步骤ST7201中，进行使用“APPkeepalive信息”的服务请求处理B。图38及图39中，作为“APPkeepalive信息”，示出进行设定以使得Uu点的RRC状态与APP会话的连接状态一致时的次序。如上述实施方式3所述，对于应用所请求发送的keep-alive分组，UE不将其向Uu点上发送。此外，网络方实体例如S-GW，进行本地APPkeepalivepacket的发送控制。因此，进行步骤ST7206～步骤ST7215的处理。上述实施方式3中，由于希望使RRC连接(RRCConnection)的状态与应用层级的会话状态一致，因此在应用层级的会话连接过程中，需要维持RRC连接(RRCConnection)。因此，在进行步骤ST5130的数据发送后，在步骤ST7216中，在数据监控定时器结束，步骤ST5134进行S1释放处理之前，会维持UE与eNB之间的RRC连接(RRCConnection)状态。这虽然可以有效避免keep-alive分组造成的影响，但作为代价，就需要使用用于维持RRC连接(RRCConnection)的无线资源。本实施方式中，提出了改善这种问题的方法。在图38的步骤ST5130进行数据发送后，相对于UE的RRC连接(RRCconnection)处于RRC_CONNECTED状态的eNB对规定期间内有无数据流向UE进行监控。或者也可以监控是否需要与UE的专用无线承载。可设置定时器作为规定期间的测量手段。以下将该定时器称为“RRC数据监控定时器”。当步骤ST7402中没有流向UE的数据、RRC数据监控定时器结束时，eNB在步骤ST7403中，启动RRC连接的释放处理。通过该处理，在步骤ST7404和步骤ST7405中，eNB与UE进入RRC_IDLE状态。在上述处理中，仅将UE与eNB之间的RRC连接状态从RRC_CONNECTED状态迁移至RRC_IDLE状态。这样，UE与eNB便可以释放用于RRC连接的无线资源。在这里，揭示了UE根据eNB发送的RRC连接释放消息进入RRC_IDLE状态的情况，但作为其他方法，也可以在UE中监控有无数据流向eNB。或者监控是否需要与eNB的专用无线承载。当没有数据产生、UE方的RRC数据监控定时器结束时，启动RRC连接的释放处理，进入RRC_IDLE状态。作为其他方法，UE也可以根据RRC的规定，进入RRC_IDLE状态。RRC的规定有例如RLF(RadioLinkFailure)等。本实施方式中，在步骤ST7404中进入RRC_IDLE状态的UE，不将进入RRC_IDLE状态的情况通知给应用。或者，进入RRC_IDLE状态的UE将进入RRC_IDLE状态的情况通知给应用，但是应用在接收到进入RRC_IDLE状态的通知时，可以不停止发送“APPkeepalivepacket”也不切断会话连接。进入RRC_IDLE状态的通知中包含表示仅RRC状态进入RRC_IDLE的信息。或者，也可以是表示UE的RRC状态、ECM状态等哪个状态进入IDLE的信息。或者，也可以是表示无线承载、S1承载、EPS承载等哪个承载被释放的信息。根据上述信息，UE的应用便可判断是否停止发送“APPkeepalivepacket”或切断会话连接。步骤ST7404中迁移至RRC_IDLE状态的UE，为了将应用会话已连接的情况通知给eNB，在步骤ST7207中，将“uukeepalivepacket”发送给eNB。“uukeepalivepacket”的发送仅在应用会话连接时进行，在步骤ST7406～步骤ST7408中，周期性地连续发送。eNB判断RRC状态，在RRC_IDLE状态下接收到“uukeepalivepacket”时，便可据此识别UE的应用的会话连接状态。UE的应用会话处于连接状态时，eNB不进行S1释放处理等S1承载以及EPS承载的释放处理。由于不进行S1释放处理，因此S-GW会创建本地keepalivepacket分组，并向应用服务器进行通知。这样，应用服务器便可识别与UE之间的连接，将会话保持在连接状态。“uukeepalivepacket”仅在UE处于RRC_IDLE时发送，但发送“uukeepalivepacket”不改变RRC状态。即，IDLE时，仅通知而不建立RRC连接(RRCconnection)。例如，使用RACH进行通知。这样，在发送“uukeepalivepacket”时，便不需要进行RRC状态的迁移，可以削减信令量。应用会话处于连接状态时，在步骤ST7409中，UE会向eNB发送“uukeepalivepacket”，但有时会因为某些原因，“uukeepalivepacket”未送达eNB的情况。例如，UE移动到eNB范围外的情况。此时，在步骤ST7410，eNB便不能在“uukeepalivepacket”发送周期的定时接收到“uukeepalivepacket”。因此，eNB能够对UE由于某些原因，不能在eNB与UE之间建立RRC连接(RRCConnection)的情况进行识别，由此来启动步骤ST5134的S1释放处理A。该处理不限于现有的S1释放处理，也可新设消息，由eNB将该UE进入RRC_IDLE状态的情况通知给S-GW。作为新设消息的具体例，如在eNB释放相对于该UE的无线资源时，设为进行S1承载的释放处理但不同时进行RRC连接处理的消息。或者，在现有的S1释放处理中，新设用于表示有无相对于该UE的无线资源的信息。该信息可为激活标志。步骤ST5134中进行了S1释放处理A后，UE在步骤ST5101中，进入RRC/ECM_IDLE状态。在步骤ST5102中，eNB相对于UE维持RRC_IDLE状态。在步骤ST5103中，MME相对于UE进入ECM_IDLE状态。在S1释放处理中，eNB与MME释放相对于UE的系统资源。在步骤ST5101中识别出进入RRC/ECM_IDLE状态的UE，在步骤ST7218中，将已进入RRC/ECM_IDLE状态的情况通知给应用。应用接收到本地释放后，判断RRC/ECM处于未连接状态，停止发送“APPkeepalivepacket”。也可切断会话连接。在步骤ST5134中将进行S1释放处理，S-GW识别出EPS承载被释放后，在步骤ST7217中，停止创建本地APPkeepalivepacket。在步骤ST7219中，S-GW将本地应用会话的释放消息通知给应用服务器。接收到本地应用会话释放消息的应用服务器判断EPS承载处于未设立的状态，可切断会话连接。通过本实施方式提出的方法，UE可以在保持应用会话连接状态的同时，迁移至RRC_IDLE。因此，便无需维持UE与eNB之间的RRC连接(RRCConnection)，可减少不必要的无线资源的使用。本实施方式提出的方法中，在RRC_IDLE状态下，需要发送“uukeepalivepacket”，因此就要使用无线资源。所以，可根据运用情况，从包含其他实施方式的方法中进行适当选择。实施方式4变形例1.实施方式4的变形例1所要解决的课题与上述实施方式4的课题相同，说明如下。实施方式4中，由于RRC数据监控定时器结束而进行RRC连接释放处理之前，是使用RRC连接(RRCConnection)状态，因此可能会产生上述实施方式2中提出的UE与eNB之间状态不一致的问题。此外，由于是根据IDLE时“uukeepalivepacket”的信息以及RRC状态这两项信息来判断应用层级的会话状态，因此挂载麻烦。为解决实施方式4的变形例1中的上述问题，将上述实施方式2的解决方案用于实施方式4。与上述实施方式2同样，发送处于RRC_CONNECTED状态的“Uukeepaliveindication”不应改变DRX的长度。此外，发送处于RRC_CONNECTED状态的“Uukeepaliveindication”与RRC数据监控定时器独立运行。即，不论RRC连接状态为何种状态，在通知了“Uukeepaliveindication”或“Uukeepalivepacket”后，UE都会将应用会话处于已连接状态通知给eNB。RRC_CONNECTED状态下使用“Uukeepaliveindication”，RRC_IDLE下使用“Uukeepalivepacket”。“Uukeepaliveindication”和“Uukeepalivepacket”可作为相同名称的消息，例如“Uukeepalive”进行使用，不受RRC连接状态的影响。图40及图41是表示实施方式4的变形例1中通信系统的次序的一个示例的图。图40与图41在边界线BL12的位置上相连。图40与图41所示的次序与图38及图39所示的次序类似，因此相同的步骤被赋予相同的步骤编号，省略相同的说明。UE与eNB在步骤ST7201的服务请求处理B(ServiceRequestProcedureB)中，进入RRC_CONNECTED状态以及ECM_CONNECTED状态。在步骤ST5130中，UE与应用服务器之间执行端到端(EndtoEnd)的服务，应用数据从UE向应用服务器进行通信。UE为维持应用会话的连接，在步骤ST7501中，向eNB发送处于RRC_CONNECTED状态的“Uukeepaliveindication”，通知应用会话处于连接状态。为了通知应用会话处于连接状态，RRC_CONNECTED状态的UE会继续周期性地向eNB发送“Uukeepaliveindication”。eNB接收到该通知后，便可了解应用会话处于连接状态。因此，eNB在接收该通知的期间，不进行S1释放处理等S1承载以及EPS承载的释放处理。由于不进行S1释放处理，因此S-GW会创建本地keepalivepacket分组，并向应用服务器进行通知。这样，应用服务器便可识别与UE之间的连接，将会话保持在连接状态。另一方面，eNB对规定期间内有无数据流向UE进行监控。也可以监控是否需要与UE的专用无线承载。可设置定时器作为规定期间的测量手段。以下将该定时器称为“RRC数据监控定时器”。当步骤ST7505中没有流向UE的数据、RRC数据监控定时器结束时，eNB在步骤ST7506中，启动RRC连接的释放处理。通过该处理，eNB与UE之间的无线承载被释放，UE与eNB在步骤ST7404及步骤ST7405，进入RRC_IDLE状态。在上述处理中，仅将UE与eNB之间的RRC连接状态从RRC_CONNECTED状态迁移至RRC_IDLE状态。这样，UE与eNB便可以释放用于RRC连接的无线资源。在这里，揭示了UE根据eNB发送的RRC连接释放消息进入RRC_IDLE状态的情况，但作为其他方法，也可以在UE中监控有无数据流向eNB。或者监控是否需要与eNB的专用无线承载。在步骤ST7404中没有数据产生、UE方的RRC数据监控定时器结束时，启动RRC连接的释放处理，进入RRC_IDLE状态。作为其他方法，UE也可以根据RRC的规定，进入RRC_IDLE状态。RRC的规定有例如RLF(RadioLinkFailure)等。进入RRC_IDLE状态的UE为维持应用会话的连接，在步骤ST7406中，向eNB发送处于RRC_IDLE状态的“Uukeepalivepacket”，通知应用会话处于连接状态。为了通知应用会话处于连接状态，RRC_CONNECTED状态的UE会继续周期性地向eNB发送“Uukeepaliveindication”。eNB接收到该通知后，便可了解应用会话处于连接状态。因此，eNB在接收该通知的期间，不进行S1释放处理等S1承载以及EPS承载的释放处理。由于不进行S1释放处理，因此S-GW会创建本地keepalivepacket分组，并向应用服务器进行通知。这样，应用服务器便可识别与UE之间的连接，将会话保持在连接状态。步骤ST7409中，在eNB确认“keepalivepacket”未送达时的处理可使用上述实施方式4的解决方案，在此省略说明。通过本实施方式提出的方法，可以减少UE与eNB之间状态不一致的现象，因此可以减轻对系统资源的影响。此外，eNB只需利用通知应用会话处于连接状态的消息便可判断应用层级的会话状态，具体而言，在RRC_CONNECTED状态时利用“uukeepaliveindication”，在RRC_IDLE状态时利用“uukeepalivepacket”，因此挂载容易。本实施方式提出的方法中，在RRC_IDLE状态和RRC_CONNECTED状态下，需要发送“uukeepaliveindication”和“uukeepalivepacket”，因此就要使用无线资源。所以，可根据运用情况，从包含其他实施方式的方法中进行适当选择。实施方式5.实施方式5所要解决的课题与上述实施方式3、实施方式3的变形例1、实施方式4以及实施方式4的变形例1的课题相同，说明如下。在上述实施方式以及变形例中，为解决因定期发送keep-alive分组而产生的问题，利用了Uu点的消息即“uukeepalive”，但仍需使用用于维持RRC连接(RRCConnection)的无线资源。本实施方式中，为解决上述课题，提出了一种不使用Uu点的消息即“uukeepalive”以及不维持RRC连接(RRCConnection)的方法。eNB与UE对规定期间内有无数据产生进行监控。eNB和UE具有会话连接判断功能，当规定期间内没有数据产生时，判断应用层级的会话已切断，当规定期间内有数据产生时，判断会话处于连接状态。eNB向某一网络装置例如S-GW通知会话连接状态的信息。接收到会话连接状态信息通知的上述网络装置即S-GW，进行本地APPkeepalivepacket的发送控制。图42及图43是表示实施方式5中通信系统的次序的一个示例的图。图42与图43在边界线BL13的位置上相连。图42与图43所示的次序与图38及图39所示的次序类似，因此相同的步骤被赋予相同的步骤编号，并省略相同的说明。步骤ST5130进行数据发送后，与UE之间的RRC连接(RRCconnection)处于RRC_CONNECTED状态的eNB监控有无数据流向UE。如上述实施方式4所述，在规定期间内没有数据流向UE、RRC数据监控定时器结束时，在步骤ST7404以及步骤ST7405中，eNB与UE进入RRC_IDLE状态。在上述处理中，仅将UE与eNB之间的RRC连接状态从RRC_CONNECTED状态迁移至RRC_IDLE状态。这样，UE与eNB便可以释放用于RRC连接的无线资源。本实施方式中，与上述实施方式4不同，迁移至RRC_IDLE状态的UE不向eNB发送用于通知会话连接的Uu点的消息即“uukeepalive”。本实施方式中，UE与eNB对规定期间内有无数据产生进行监控。eNB和UE具有会话连接判断功能，当规定期间内没有数据产生时，判断应用层级的会话已切断，当规定期间内有数据产生时，判断会话处于连接状态。这里，eNB与UE是对规定期间内有无数据产生进行监控，但也可以对是否需要相对于UE的S1承载进行监控。此外，也可以对是否需要相对于UE的ECM_CONNECTED状态进行监控。可设置定时器作为规定期间的测量手段。以下将该定时器称为“NAS数据监控定时器”。UE可以将会话连接判断功能作为NAS功能。或者，也可以作为AS的功能。作为AS的功能时，可以在NAS数据监控定时器结束时，由AS向NAS通知该信息。eNB可以将会话连接判断功能作为AS的功能。UE监控有无数据产生，在步骤ST7601中NAS数据监控定时器结束时，在步骤ST5101中，UE进入RRC/ECM_IDLE状态。在步骤ST5101中识别出进入RRC/ECM_IDLE的UE，在步骤ST7218中，将已进入RRC/ECM_IDLE状态的情况通知给应用。应用接收到本地释放后，判断RRC/ECM处于未连接状态，停止发送“APPkeepalivepacket”。也可切断会话连接。eNB监控有无数据产生，在步骤ST7602中NAS数据监控定时器结束时，启动在步骤ST5134的S1释放处理A。步骤ST5134中进行了S1释放处理A后，eNB在步骤ST5102中，相对于UE维持RRC_IDLE状态。在步骤ST5103中，MME相对于UE进入ECM_IDLE状态。在S1释放处理中，eNB与MME释放相对于UE的系统资源。在步骤ST5134中进行S1释放处理A，识别出EPS承载被释放的S-GW在步骤ST7217中，停止创建本地APPkeepalivepacket。在步骤ST7219中，S-GW将本地应用会话的释放消息通知给应用服务器。接收到本地应用会话释放消息的应用服务器判断EPS承载处于未设立的状态，可切断会话连接。上述方法中，揭示了UE与eNB具有会话连接判断功能。作为其他方法，也可以使UE不具有会话连接判断功能，而使eNB具有会话连接判断功能。此时，eNB对有无数据产生进行监控，当NAS数据监控定时器结束时，启动S1释放处理。通过进行S1释放处理，UE进入RRC/ECM_IDLE状态。UE识别出进入RRC/ECM_IDLE后，将已进入RRC/ECM_IDLE状态的情况通知给应用。应用接收到本地释放后，判断RRC/ECM处于未连接状态，停止发送“APPkeepalivepacket”。也可切断会话连接。这样，便无需在UE方进行NAS数据监控，控制更加简单。通过本实施方式提出的方法，无需使用用于通知会话连接的Uu点的消息即“uukeepalive”，也无需维持RRC连接(RRCConnection)，便可进行会话连接判断。这样，便可削减无线资源的使用量。此外，仅利用RRC数据监控定时器以及NAS数据监控定时器等数据监控定时器，便可控制RRC连接状态的迁移以及应用会话连接状态的迁移，因此挂载容易。此外，可以使本实施方式中提出的NAS数据监控定时器与应用所具备的会话定时器一致。UE事先将会话定时器通知给eNB即可。这样，便可使应用的连接控制时间与通信系统上的连接控制时间相一致，可减少系统的误动作。在包含变形例的其他实施方式中，也可以使NAS数据监控定时器与应用所具备的会话定时器一致。此外，在考虑应用特性的基础上使用本实施方式所提出的方法，可以更加有效，例如将本实施方式的方法用于能够将设想不会进行频繁连接的NAS数据监控定时器的值设定得较短的应用等中。实施方式6.以下，针对实施方式6所解决的课题，进行说明。对于经常会启动即时消息以及SNS(SocialNetworkingService：社交网络服务)等，定期收发较小规模数据的应用而言，也会产生与上述实施方式3相同的问题。此时，需要向实际成为发送对象服务器等传送信息，因此不能直接使用上述实施方式3～实施方式5的解决措施。例如非专利文献15及非专利文献16中，提出了一种无需为用户数据开设专用的无线接入承载，而使用NAS信令用承载进行传送的概念。本提案中，将通信端到端(EndtoEnd)作为UE与某PDN(PublicDataNetwork：公共数据网络)中的服务器时，在与该PDN对应的P-GW与包含对象UE在内的MME之间，设定数据传送用的会话，使用数据传送用的路径与NAS信令用的承载进行通信。非专利文献15的图1(a)示出了概念图。图1(a)的结构中的通信为准连接(connection-lite)型通信，图1(b)的结构中的通信为面向连接(connection-oriented)型通信。非专利文献16的图1中，示出了使用非专利文献15的图1(a)执行时所设定的与PDN的连接步骤。在此，对于UE发出的PDN连接请求，建立了IP连接接入网络(IP-CAN)的会话。另外，在上述非专利文献15中，暗示了connection-lite与connection-oriented的同时使用。根据非专利文献15，需要发送connection-lite中不应发送的大规模数据时，暗示通过通常的传送路径(connection-oriented)进行传送。然而，其实现方法，例如connection-lite与connection-oriented的切换方法等并没有明确说明。因此，产生了无法切换使用connection-lite与connection-oriented，从而无法构建稳定的通信系统的问题。实施方式6中提出了如下解决方法。本实施方式中，提出了connection-lite与connection-oriented的切换方法。UE、P-GW、或S-GW判断是通过connection-lite发送还是通过connection-oriented发送。作为判断方法的具体例，揭示以下(1)～(3)的3种。(1)根据数据判断。具体而言，根据数据的大小判断。(2)根据状态判断。(3)上述(1)、(2)的组合。需要说明的是，在UE发送数据和APP服务器发送数据的两种情况下，connection-lite和connection-oriented的切换方法可以相同，也可以不同。作为不同情况下的具体例，例如在UE发送数据时，采用connection-lite，在APP服务器发送数据时采用connection-oriented等。作为根据数据判断的方法的具体例，可举出以下(1)、(2)的两种。(1)数据量大于阈值时，判断采用connection-oriented进行发送，在阈值以下时，判断采用connection-lite进行发送。(2)通信量大于阈值时，判断采用connection-oriented进行发送，在阈值以下时，判断采用connection-lite进行发送。判断是否是较小的通信量即可。作为通信量的具体例，例如为某单位时间内的数据量。如非专利文献16所公开的那样，在利用数据量进行判断时，可能会以分组单位进行connection-lite和connection-oriented的切换。另一方面，利用通信量判断时，单位时间内不会发生connection-lite和connection-oriented的切换，因此可获得减少控制开销的效果。上述所揭示的阈值在UE、P-GW和S-GW中可以是不同的值。上行与下行的阈值也可以设为不同的值。针对P-GW或S-GW内的结构以及UE内的结构，可优化作为小数据处理的数据量或通信量。根据上行和下行的负荷状况，可优化作为小数据处理的数据量或通信量。以下，有时也将判断为采用connection-oriented发送的数据称为正常大小的数据(Normalsizedata)。另外，有时也将判断为采用connection-lite发送的数据称为小规模数据或小数据(smalldata)。作为上述阈值例如数据量的阈值以及通信量的阈值的决定方法的具体例，揭示以下(1)～(9)的9种。(1)可依据应用来决定。可依据应用所请求的连接对象来决定。UE的NAS、P-GW、或S-GW可根据应用所请求的QoS、QCI、承载信息等，来决定阈值。(2)eNB、MME可根据eNB与MME之间的通信系统的状态来决定。也可以根据S1接口的通信系统状态来决定。作为通信系统的状态的具体例，有静态决定的最大传送能力、负荷状况等。(3)MME、S-GW可根据MME与S-GW之间的通信系统的状态来决定。也可以根据S11接口的通信系统状态来决定。作为通信系统的状态的具体例，有静态决定的最大传送能力、负荷状况等。(4)可依据运营商政策来决定。也可依据小数据发送政策来决定。小数据发送政策可由运营商设定。(5)可根据S-GW与P-GW之间的接口即S5/S8接口的通信系统的状态来决定。可由P-GW或S-GW决定。(6)可由OAM决定。(7)根据UE的能力来决定。(8)上述(1)～(7)的组合。(9)以静态方式决定。作为阈值的通知方法的具体例，揭示以下(1)～(8)的8种。(1)不通知。使用阈值的决定方法(1)时，UE与S-GW或P-GW分别依据相同的应用决定阈值即可。使用阈值的决定方法(5)时，也不需要通知。通知方法(1)无需考虑通信错误，并可减少控制负荷，这一点比以下通知方法(2)～(4)有效。(2)将eNB决定的值通知给UE、S-GW或P-GW。(3)将MME决定的值通知给UE、S-GW或P-GW。(4)将S-GW决定的值通知给UE和P-GW。也可使用TFT(TrafficFlowTemplates，流量模板)进行通知。通过使用TFT通知小数据发送政策与阈值，可以获得以下效果。可以将小数据发送政策、和用于判断是采用connection-lite发送的小数据还是采用connection-oriented发送的正常大小数据的阈值一起进行通知。由于能够同时接收判断采用connection-lite还是connection-oriented所需的“小数据发送政策”和“阈值”，因此处理更容易。(5)将P-GW决定的值通知给UE。也可使用TFT(TrafficFlowTemplates，流量模板)进行通知。通过使用TFT通知小数据发送政策与阈值，可以获得以下效果。可以将小数据发送政策、和用于判断是采用connection-lite发送的小数据还是采用connection-oriented发送的正常大小数据的阈值一起进行通知。由于能够同时接收对采用的是connection-lite还是connection-oriented进行判断所需的“小数据发送政策”和“阈值”，因此处理更容易。(6)将运营商决定的值通知给P-GW或S-GW以及UE。(7)将OAM决定的值通知给P-GW或S-GW以及UE。(8)在网络方实体与UE之间交换小数据发送政策时，附带进行阈值的交换。由于能够同时接收对采用的是connection-lite还是connection-oriented进行判断所需的“小数据发送政策”和“阈值”，因此处理更容易。针对根据状态进行判断的方法的具体例，说明如下。根据与成为对象的UE之间的ECM连接状态以及RRC连接状态，判断是采用connection-lite进行通信还是采用connection-oriented进行通信。即使已经建立EPS承载(EPSbearer)，有时也仍然处于ECM_IDLE状态以及RRC_IDLE状态。因此，将与成为对象的UE之间的ECM连接状态以及RRC连接状态作为切换的判断基准的方法与将有无建立EPS承载作为切换的判断基准的方法相比，可防止承载连接中需要大量信令的情况。以下说明具体例。在ECM_CONNECTED且RRC_CONNECTED的情况下，可采用connection-oriented进行通信。无论产生的数据量或通信量多少，可以都采用connection-oriented进行通信。即使产生小数据(smalldata)，仍然采用connection-oriented进行通信。在ECM_IDLE或RRC_IDLE的情况下，在产生小数据时采用connection-lite进行通信，在产生正常大小数据时采用connection-oriented进行通信。即使已经建立了EPS承载，在ECM_IDLE时，S1-U或RRC也未必处于连接状态。因此，当产生小数据时，采用connection-lite进行通信，便可削减U-plane连接所需的信令。此外，在RRC_IDLE的情况下采用connection-lite进行通信时，可不进入RRC_CONNECTED状态。这样，便无需启动RRC连接设置处理(RRCConnectionSetupProcedure)。具体方法有例如使用RACH处理发送小数据，或通过寻呼处理发送小数据等。使用RACH处理发送小数据的方法与上述实施方式1的变形例4相同，因此省略说明。使用寻呼处理发送小数据的方法与上述实施方式1的变形例5相同，因此省略说明。以上说明的判断基准可以附加在小数据发送政策上，由UE以及S-GW或P-GW拥有。也可以独立于小数据发送政策，作为数据(data)发送政策，由UE以及S-GW或P-GW拥有。需要说明的是，在上述说明中，是根据与成为对象的UE之间的ECM连接状态以及RRC连接状态，来判断采用connection-lite进行通信还是采用connection-oriented进行通信，但并非仅限于此，也可以根据与成为对象的UE之间的S1-U承载的建立状态以及无线承载的建立状态，判断是采用connection-lite进行通信还是采用connection-oriented进行通信。此时，只需将ECM连接状态置换为S1-U承载的建立状态，将RRC连接状态置换为无线承载的建立状态即可。UE发送数据时(也称为MO)，UE判断是采用connection-lite进行通信还是采用connection-oriented进行通信。因此，UE需要事先识别RRC状态或ECM状态。UE已经识别了RRC状态。以前，RRC状态与ECM状态是一致的，因此UE也能够识别ECM状态。然而，在实施方式4、实施方式5或下述的实施方式7中，有时RRC状态与ECM会不同。这种情况下，UE就无法识别ECM状态。这个问题可以采用以下方法来解决。RRC状态与ECM状态不同时，可从MME或eNB向UE通知表示ECM状态的信息。APP服务器发送数据时(也称为MT)，P-GW或S-GW判断是采用connection-lite进行通信还是采用connection-oriented进行通信。因此，P-GW或S-GW需要事先识别RRC状态或ECM状态。S-GW已经识别了ECM状态。以前，RRC状态与ECM状态是一致的，因此S-GW也能够识别RRC状态。然而，在实施方式4、实施方式5或下述的实施方式7中，有时RRC状态与ECM状态会不同。这种情况下，S-GW就无法识别RRC状态。这个问题可以采用以下方法来解决。RRC状态与ECM状态不同时，可从eNB向S-GW通知表示RRC状态的信息。并且，也可从UE向S-GW通知表示RRC状态的信息。P-GW不一定识别了RRC状态以及ECM状态。MME可将表示ECM状态的信息通知给P-GW。并且，S-GW也可将表示ECM状态的信息通知给P-GW。eNB可将表示RRC状态的信息通知给P-GW。并且，UE也可将表示RRC状态的信息通知给P-GW。这样，在MO中，UE便可判断是采用connection-lite进行通信还是采用connection-oriented进行通信，而在MT中，P-GW或S-GW便可判断是采用connection-lite进行通信还是采用connection-oriented进行通信。以下说明从connection-lite切换到connection-oriented的方法。在Connection-lite的状态下，当UE判断采用connection-oriented进行发送时，UE启动服务请求处理(ServiceRequestProcedure)。该处理与通常的呼叫处理相同，因此可获得避免通信系统复杂化的效果。在Connection-lite状态下，P-GW以及S-GW等网络方判断采用connection-oriented进行发送时，P-GW启动专用承载激活处理(DedicatedBearerActivationProcedure)(参考非专利文献13第5.4.1章)。该处理与通常的应答处理相同，因此可获得避免通信系统复杂化的效果。在发生从connection-lite切换到connection-oriented的情况时，在S1-MME和S11上，可不激活小数据发送功能和设定。例如，可不激活在NAS消息中包含小数据的功能及设定、在GTP-C中包含小数据的功能及设定等。当另外发生信令或再次切换至connection-lite时，无需重新设定，因此可获得能够减轻通信系统处理负荷的效果。接下来，使用图44～图47，说明实施方式6中通信系统的次序的具体例。图44～图47是表示实施方式6中通信系统的次序的一个示例的图。图44与图45在边界线BL14的位置上相连。图45与图46在边界线BL15的位置上相连。图46与图47在边界线BL16的位置上相连。图44～图47示出在connection-lite状态下，UE方传送大数据时，迁移至connection-oriented状态时的次序。首先在图44及图45的步骤ST9101～9122中，示出非专利文献16中所公开的执行connection-lite时设定的PDN连接步骤。在步骤9101中，UE的应用或TPC/IP向NAS提出接入请求(AccessRequest)。在步骤ST9102中，UE的NAS启动PDN建立处理(PDNEstablishmentProcedure)。步骤ST9102的PDN建立处理包含步骤ST9103～步骤ST9121的处理。步骤ST9103中，UE的NAS向AS(AccessStratum)发送PDN连接请求(PDNConnectivityRequest)消息。UE的NAS也可以通知RRC层。在步骤ST9104中，UE的RRC层启动RRC连接设置处理(RRCConnectionSetupProcedure)。步骤ST9104的RRC连接设置处理包含步骤ST9105～步骤ST9107的处理。在步骤ST9105中，UE的RRC层向eNB发送RRC连接设置请求(RRCConnectionSetupRequest)消息。在步骤ST9105中接收到RRC连接设置请求消息的eNB在步骤ST9106中，向UE的RRC层发送RRC连接设置(RRCConnectionSetup)消息。在步骤ST9106中接收到RRC连接设置消息的UE在步骤ST9107中，向eNB发送RRC连接设置完成(RRCConnectionSetupComplete)消息。步骤ST9108中，UE的RRC层向eNB发送PDN连接请求(PDNConnectivityRequest)消息。在步骤ST9108中接收到PDN连接请求消息的eNB在步骤ST9109中，将PDN连接请求消息发送给MME。在步骤ST9110中，MME向S-GW发送创建会话请求(CreateSessionRequest)消息。在步骤ST9110中接收到创建会话请求消息的S-GW在步骤ST9111中，将创建会话请求消息发送给P-GW。在步骤ST9112中，P-GW执行IP连接接入网络(IP-CAN)的会话建立(IP-CANSessionEstablishment)。在步骤ST9112中完成IP-CAN的会话建立后，在步骤ST9113中，P-GW向S-GW发送创建会话响应(CreateSessionResponse)消息。在步骤ST9113中接收到创建会话响应消息的S-GW，在步骤ST9114中，将创建会话响应消息发送给MME。在步骤ST9115中，MME向eNB发送激活默认承载上下文请求(ActivateDefaultBearerContextRequest)消息。在步骤ST9115中接收到激活默认承载上下文请求消息的eNB在步骤ST9116中，将激活默认承载上下文请求消息发送给UE。在步骤ST9116中接收到激活默认承载上下文请求消息的UE在步骤ST9117中，将激活默认承载上下文响应(ActivateDefaultBearerContextResponse)消息发送给eNB。在步骤ST9117中接收到激活默认承载上下文响应消息的eNB在步骤ST9118中，将激活默认承载上下文响应消息发送给MME。然后，使用上述PDN连接步骤，在网络方实体与UE之间交换小数据(smalldata)发送政策。这样，在发送小数据时，UE与应用服务器之间，便可以经由eNB、MME、S-GW、P-GW进行小数据发送。在步骤ST9119中，在MME和S-GW之间建立S11承载(S11Bearer)。在MME与S-GW之间的S11上，可进行小数据发送(S11(sml))。在步骤ST9120中，在S-GW和P-GW之间建立S5/S8承载(S5/S8Bearer)。在S-GW与P-GW之间的S5/S8上，可进行小数据发送(S5/S8(sml))。在步骤ST9121中，在eNB和MME之间建立S1承载(S1Bearer)。在eNB与MME之间的S1上，可进行小数据发送(S1(sml))。这样，在步骤ST9122中，就可以从UE，经由eNB、MME、S-GW、P-GW，向应用服务器(APPServer)发送数据。以下，也将这种状态称为“connection-lite状态”。也可使其能够发送小数据。在图46的步骤ST9123中，从UE的应用向NAS提出正常大小的数据发送请求，从而对发送数据进行发送。在步骤ST9123中接收到正常大小数据的UE的NAS在步骤ST9124中，判断是采用connection-lite发送还是采用connection-oriented发送。此处省略了图示，但可根据上述状态进行判断。具体而言，判断发送数据是否是小数据。在步骤ST9124中判断是小数据时，判断采用connection-lite发送，进入步骤ST9125。在步骤ST9124中判断不是小数据时，判断采用connection-oriented发送，进入步骤ST9126。在步骤ST9125中，UE的NAS在connection-lite状态下发送数据。也可使用为小数据而设立的承载、在connection-lite下完成设立的承载(以下也称为“Connectionlitebearer”)进行发送。步骤ST9126中，UE的NAS开始准备在connection-oriented下进行发送。作为具体例，例如有启动服务请求处理C(ServiceRequestProcedureC)。步骤ST9126的服务请求处理C包含步骤ST9127～步骤ST9147的处理。步骤ST9127中，UE的NAS向AS发送服务请求(ServiceRequest)消息。UE的NAS也可以通知RRC层。在步骤ST9127中接收到服务请求消息的UE在步骤ST9128中，启动RRC连接设置处理(RRCConnectionSetupProcedure)。RRC连接设置处理的详细情况与图44中步骤ST9104的处理相同，因此省略说明。步骤ST9132中，UE的RRC层向eNB发送服务请求(ServiceRequest)消息。在步骤ST9132中接收到服务请求消息的eNB在步骤ST9133中，将服务请求(ServiceRequest)消息发送给MME。在步骤ST9133中接收到服务请求消息的MME在图47的步骤ST9134中，将初始上下文设置请求(InitialContextSetupRequest)消息发送给eNB。在步骤ST9134中接收到初始上下文设置请求消息的eNB在步骤ST9135中，启动无线承载建立处理(RadioBearerEstablishmentProcedure)。步骤ST9135的无线承载建立处理包含步骤ST9136～步骤ST9137的处理。在步骤ST9136中，eNB将RRC连接重配置(RRCConnectionReconfiguration)消息发送给UE。在步骤ST9136中接收到RRC连接重配置消息的UE在步骤ST9137中，向eNB发送RRC连接重配置完成(RRCConnectionReconfigurationComplete)消息。在步骤ST9137中接收到RRC连接重配置完成消息的eNB在步骤ST9138中，将初始上下文设置完成(InitialContextSetupComplete)消息发送给MME。在步骤ST9139中，MME向S-GW发送修改承载请求(ModifyBearerRequest)消息。在步骤ST9139中接收到修改承载请求消息的S-GW在步骤ST9141中，将修改承载请求(ModifyBearerRequest)消息发送给P-GW。在步骤ST9142中，P-GW执行IP连接接入网络(IP-CAN)会话修改(IP-CANSessionModification)。IP-CAN的会话修改有时称为“PCEFinitiatedIP-CANSessionModification”。在步骤ST9142中完成IP-CAN的会话修改后，在步骤ST9143中，P-GW向S-GW发送修改承载响应(ModifyBearerResponse)消息。在步骤ST9143中接收到修改承载响应消息的S-GW在步骤ST9144中，将修改承载响应(ModifyBearerResponse)消息发送给MME。在步骤ST9145中，在eNB和S-GW之间建立S1承载(S1Bearer)。在步骤ST9146中，在S-GW和P-GW之间建立S5/S8承载(S5/S8Bearer)。在步骤ST9147中，在UE和P-GW之间建立EPS承载(EPSBearer)。这样，在步骤ST9148中，就可以从UE，经由eNB、S-GW、P-GW，向应用服务器(APPServer)发送数据。以下，也将这种状态称为connection-oriented状态。也可使其能够发送正常大小数据。接下来，使用图48及图49，说明实施方式6中通信系统的次序的具体例。图48及图49是表示实施方式6中通信系统的次序的其他示例的图。图48与图49在边界线BL17的位置上相连。图48与图49所示的次序与图44～图47所示的次序类似，因此相同的步骤被赋予相同的步骤编号，省略相同的说明。图48及图49示出在connection-lite状态下，网络(NW)方传送大数据时，迁移至connection-oriented状态时的次序。在步骤ST9201中，从应用服务器向P-GW提出正常大小的数据发送请求，从而对发送数据进行发送。在步骤ST9201中接收到正常大小数据的P-GW在步骤ST9202中，判断是采用connection-lite发送还是采用connection-oriented发送。具体而言，判断发送数据是否是小数据。此处省略了图示，但可根据上述状态进行判断。在步骤ST9202中判断是小数据时，判断采用connection-lite发送，进入步骤ST9203。在步骤ST9202中判断不是小数据时，判断采用connection-oriented发送，进入步骤ST9204。在步骤ST9203中，P-GW在connection-lite状态下发送数据。也可使用准连接承载(connectionlitebearer)进行发送。步骤ST9204中，P-GW开始准备在connection-oriented下进行发送。作为具体例，例如有启动专用承载激活处理(DedicatedBearerActivationProcedure)。步骤ST9204的专用承载激活处理包含步骤ST9205～步骤ST9146的处理。在步骤ST9205中，P-GW向S-GW发送创建承载请求(CreateBearerRequest)消息。在步骤ST9205中接收到创建承载请求消息的S-GW在步骤ST9206中，将创建承载请求消息发送给MME。在步骤ST9206中接收到创建承载请求消息的MME在步骤ST9135中，启动无线承载建立处理(RadioBearerEstablishmentProcedure)。在步骤ST9208中，eNB将承载建立响应(BearerSetupResponse)消息发送给MME。在步骤ST9209中，UE向eNB发送“DirectTransfer”。或者也可发送会话管理响应(SessionManagementResponse)消息。在步骤ST9209中接收到会话管理响应消息的eNB在步骤ST9210中，将会话管理响应消息发送给MME。在步骤ST9210中接收到会话管理响应消息的MME在步骤ST9211中，将创建承载响应(CreateBearerResponse)消息发送给S-GW。在步骤ST9211中接收到创建承载响应消息的S-GW在步骤ST9212中，将创建承载响应消息发送给P-GW。通过以上实施方式6，可获得以下效果。可实现connection-lite与connection-oriented的同时使用。通过决定实现方法，便可以构建稳定的通信系统。实施方式6变形例1.以下，针对实施方式6的变形例1所解决的课题，进行说明。进行上述实施方式6时，会产生以下课题。例如，在执行图44～图47所示次序后，虽然是连接到相同的应用服务器，但是IP连接接入网络(IP-CAN)的会话建立在例如图45的步骤ST9112和图47的步骤9142中，会进行双重设定。此时，在某些情况下，就会对相同的应用会话执行不必要的手续。并且，有时PDN方可能会将其作为非法请求，而不允许连接，因此会出现问题。此外，在connection-lite状态下，UE与NW双方发送正常大小的数据时，会产生以下问题。基于UE发出的服务请求(ServiceRequest)，启动无线承载建立处理(RadioBearerEstablishmentProcedure)，基于P-GW发出的创建承载请求(CreateBearerRequest)，无论是不是相同的承载，都会再次进行无线承载(RadioBearer)的设定。下面使用图50及图51，说明实施方式6的变形例1的课题的具体例。图50及图51是表示用于说明实施方式6的变形例1所解决课题的次序的图。图50与图51在边界线BL18的位置上相连。图50与图51所示的次序与图44～图47、图48及图49所示的次序类似，因此相同的步骤被赋予相同的步骤编号，省略相同的说明。图50和图51中，为了建立相同的无线承载(RadioBearer)，在步骤ST9135中，会重复启动无线承载建立处理(RadioBearerEstablishmentProcedure)。实施方式6的变形例1中提出了如下解决方法。当存在准连接承载(connectionlitebearer)时，或存在已通过connection-oriented建立完成的承载(以下有时称为“Connectionorientedbearer”)时，P-GW不执行IP-CAN会话(IP-CANsession)的相关手续。或者，根据最初设定的PDN连接请求(PDNConnectivityRequest)，维持IP连接接入网络(IP-CAN)的会话，P-GW不执行IP-CAN会话的相关的手续。这样，便可防止对相同的应用会话执行不必要的手续。然后，MME判断UE与P-GW之间connection-oriented状态下使用的承载是否处于建立步骤中、修改步骤中、或者建立完成状态。以下，有时也将该判断称为“有无建立承载判断”。如果不是在建立步骤中、修改步骤中或者建立完成状态，则启动在connection-oriented状态下使用的承载的建立手续。或者，MME判断RRC/ECM状态是CONNECTED还是IDLE，如果是IDLE，则启动connection-oriented状态下使用的承载的建立手续。如果是在建立步骤中、修改步骤中或者建立完成状态，则不启动在connection-oriented状态下使用的承载的建立手续。或者，MME判断RRC/ECM状态是CONNECTED还是IDLE，如果是CONNECTED，则不启动connection-oriented状态下使用的承载的建立手续。这样，便可以避免承载的重复设定。以下说明UE发送数据的情况。MME可以在接收到服务请求(ServiceRequest)后，启动有无建立承载判断。如果不是在建立步骤中或者建立完成状态，则启动在connection-oriented状态下使用的承载的建立手续。作为具体例，例如根据正常的服务请求处理(ServiceRequestProcedure)进行处理。例如，MME向eNB发送初始上下文设置请求(InitialContextSetupRequest)消息。如果是在建立步骤中或者建立完成状态，则将该内容通知给UE。或者也可不进行通知而结束处理。以下说明APP服务器发送数据的情况。P-GW或S-GW从应用服务器接到数据发送请求，从而对发送数据进行发送时，启动有无现有承载的判断。判断有现有承载时，将该内容通知给MME。可以只在有现有承载时通知MME。可新设一个由P-GW向MME通知的消息作为通知方法。例如，修改承载请求(BearerChangeRequest)消息等。或者，也可以在现有的创建承载请求(CreateBearerRequest)消息中追加表示有现有承载的信息要素。接收到修改承载请求消息的MME可启动有无建立承载判断。如果不是在建立步骤中或者建立完成状态，则启动在connection-oriented状态下使用的承载的建立手续。作为具体例，例如MME向P-GW请求启动正常的专用承载激活处理(DedicatedBearerActivationProcedure)。作为请求方法的具体例，例如新设创建承载响应(CreateBearerResponse)或修改承载响应(BearerChangeResponse)，或者新设建立承载请求(BearerSetRequest)。对于修改承载请求(BearerChangeRequest)，可发送拒绝(Reject)信号，并将作为其理由的处于建立步骤中或建立完成状态的内容加以通知。或者，MME自己向eNB发送承载设置请求/会话管理请求(BearerSetupRequest/SessionManagementRequest)，启动专用承载激活处理(DedicatedBearerActivationProcedure)。如果是在建立步骤中或者建立完成状态，则将该内容通知给P-GW。作为通知方法的具体例，例如修改承载请求(ModifyBearerRequest)或修改承载响应(BearerChangeResponse)等。接收到表示处于建立步骤中或建立完成状态的消息的P-GW使用新建立的承载，向UE发送下行数据。在以上方法中，MME判断UE与P-GW之间connection-oriented状态下使用的承载是否处于建立步骤中、或者建立完成状态。作为其他方法，也可以由UE或者P-GW或S-GW判断在UE与P-GW之间，connection-oriented状态下使用的承载是否处于建立完成状态，然后通知给P-GW或MME。以下说明UE发送数据的情况。UE判断是否存在准连接承载(connectionlitebearer)或面向连接承载(connectionorientedbearer)。以下，有时也将该判断称为“现有承载有无判断”。UE将现有承载有无判断结果通知给网络方。具体而言，UE向P-GW或S-GW进行通知。作为现有承载有无判断结果的通知内容的具体例揭示以下(1)～(3)的3种。(1)现有承载的有无。或只是有现有承载的内容。或只是没有现有承载的内容。(2)是否需要修改EPS承载。或者只是需要修改EPS承载的内容。或者只是不需要修改EPS承载的内容。有现有承载时，无需修改EPS承载，没有现有承载时，需要修改EPS承载。(3)是否需要IP-CAN会话相关的手续。或者只是需要IP-CAN会话相关的手续的内容。或者只是不需要IP-CAN会话相关的手续的内容。有现有承载时，不需要IP-CAN会话相关的手续，没有现有承载时，需要IP-CAN会话的相关手续。下文揭示了作为现有承载有无判断结果的通知方法的具体例。UE经由MME向P-GW或S-GW进行通知。例如，UE使用NAS信号，将现有承载有无判断结果通知给MME。作为这种情况的具体例，揭示以下(1)、(2)的两种。(1)新设NAS信号。(2)使用现有的NAS信号。可在现有信号中追加现有承载有无判断的信息要素。作为现有信号的具体例，有服务请求(ServiceRequest)消息等。接收到现有承载有无判断结果的MME，将从UE接收到的现有承载有无判断的结果通知给S-GW、P-GW。作为这种情况的具体例，揭示以下(1)、(2)的两种。(1)新设信号。(2)使用现有的信号。可在现有信号中追加现有承载有无判断的信息要素。作为现有信号的具体例，有修改承载请求(ModifyBearerRequest)消息、删除承载请求(DeleteBearerRequest)消息等。接收到现有承载有无判断结果的S-GW或P-GW依据接收到的现有承载有无判断的结果，判断是否执行IP-CAN会话相关的手续。具体采用以下(1)、(2)的方式进行判断。(1)在接收到有现有承载或无需修改EPS承载、不需要IP-CAN会话相关的手续的通知时，判断不需要IP-CAN会话相关的手续。无论修改承载请求(ModifyBearerRequest)等中参考的动态PCC(DynamicPCC)状态如何，P-GW均可判断不需要IP-CAN会话相关的手续。(2)在接收到没有现有承载或需要修改EPS承载、需要IP-CAN会话相关的手续的通知时，判断需要IP-CAN会话相关的手续。以下说明APP服务器发送数据的情况。这种情况下，由P-GW或S-GW进行现有承载有无的判断。根据其结果，S-GW或P-GW判断是否执行IP-CAN会话相关的手续。具体采用以下(1)、(2)的方式进行判断。(1)有现有承载时，判断不需要IP-CAN会话相关的手续。(2)没有现有承载时，判断需要IP-CAN会话相关的手续。作为具体例，例如有启动正常的专用承载激活处理(DedicatedBearerActivationProcedure)。接下来，使用图52及图53，说明实施方式6的变形例1中通信系统的次序的具体例。图52及图53是表示实施方式6的变形例1中通信系统的次序的一个示例的图。图52与图53在边界线BL19的位置上相连。图52与图53所示的次序与图44～图47所示的次序类似，因此相同的步骤被赋予相同的步骤编号，省略相同的说明。图52及图53示出在connection-lite状态下，UE方传送大数据时，迁移至connection-oriented状态时的次序。在步骤ST9401中，UE执行现有承载有无的判断。也可由UE的NAS判断。当判断没有现有承载时，UE启动正常的服务请求处理(ServiceRequestProcedure)。图52及图53中，省略了正常的服务请求处理的说明，记为“结束”。判断有现有承载时，UE进入步骤ST9402。在步骤ST9402中，UE的NAS向AS发送追加了现有承载有无判断的信息要素的服务请求(ServiceRequest)。UE的NAS也可以通知RRC层。在图53的步骤ST9403中，UE的RRC层向eNB发送追加了现有承载有无判断的信息要素的服务请求(ServiceRequest)消息。eNB在步骤ST9403中接收到追加了现有承载有无判断的信息要素的服务请求消息后，在步骤ST9404中，向MME发送追加了现有承载有无判断的信息要素的服务请求(ServiceRequest)消息。MME在步骤ST9404中接收到服务请求消息后，判断面向连接承载(connectionorientedbearer)是处于建立步骤中还是建立完成状态。即，执行有无建立承载的判断。根据现有承载有无判断的结果，MME在接收到有现有承载的通知时，可执行有无建立承载判断。处于建立步骤中或者建立完成状态时，结束处理。MME也可根据需要，经由eNB向UE发送响应消息。UE接收到响应消息后，等待正在建立的承载的RRC连接(RRCconnection)的设定，进行正常数据的发送。不存在响应消息时，也可通过正在建立或已经建立的承载的RRC连接(RRCconnection)设定进行发送。不是处于建立步骤中或者建立完成状态时，进入步骤ST9410，MME向eNB发送初始上下文设置请求(InitialContextSetupRequest)消息。也可在初始上下文设置请求消息中追加现有承载有无判断的信息要素。在步骤ST9411中，eNB向MME发送初始上下文设置完成(InitialContextSetupComplete)消息。也可在初始上下文设置完成消息中追加现有承载有无判断的信息要素。步骤ST9406中，MME向S-GW发送追加了现有承载有无判断信息要素的修改承载请求(ModifyBearerRequest)。S-GW在步骤ST9406中接收到追加了现有承载有无判断的信息要素的修改承载请求消息后，在步骤ST9407中，向P-GW发送追加了现有承载有无判断的信息要素的修改承载请求(ModifyBearerRequest)消息。P-GW在步骤ST9407中接收到追加了现有承载有无判断的信息要素的修改承载请求消息后，不执行IP-CAN会话相关手续。在步骤ST9408中，P-GW向S-GW发送修改承载响应(ModifybearerResponse)。也可与未修改EPS承载或未执行IP-CAN会话相关手续的内容一同通知。S-GW在步骤ST9408中接收到修改承载响应消息后，在步骤ST9409中，将修改承载响应(ModifybearerResponse)消息发送给MME。接下来，使用图54～图56，说明实施方式6的变形例1中通信系统的次序的具体例。图54～图56是表示实施方式6的变形例1中通信系统的次序的其他示例的图。图54与图55在边界线BL20的位置上相连。图55与图56在边界线BL21的位置上相连。图54～图56所示的次序与图44～图49所示的次序类似，因此相同的步骤被赋予相同的步骤编号，省略相同的说明。图54～图56示出在connection-lite状态下，网络(NW)方传送大数据时，迁移至connection-oriented状态时的次序。图55的步骤ST9501中，P-GW执行现有承载有无的判断。P-GW判断没有现有承载时，进入步骤ST9204，启动正常的专用承载激活处理(DedicatedBearerActivationProcedure)。P-GW判断有现有承载时，进入步骤ST9502。在步骤ST9502中，P-GW通知MME有现有承载。具体而言，将修改承载请求(BearerChangeRequest)消息通知给MME。MME在步骤ST9502中接收到有现有承载的内容后，在步骤ST9405中，判断面向连接承载(connectionorientedbearer)是否处于建立步骤中或者建立完成状态。即，执行有无建立承载的判断。处于建立步骤中或者建立完成状态时，进入步骤ST9501，MME将该情况通知P-GW。没有处于建立步骤中或者建立完成状态时，进入步骤ST9504，MME向P-GW请求启动正常的专用承载激活处理(DedicatedBearerActivationProcedure)。在图56的步骤ST9505中，P-GW使用步骤ST9148中建立的承载，向UE发送数据。即，进行正常大小的数据(Normalsizedata)发送，然后结束处理。在步骤ST9506中，P-GW判断有无建立新的承载。判断为未建立时，重复步骤ST9506的判断。判断为已建立时，进入步骤ST9507。在步骤ST9507中，P-GW使用新建立的承载，向UE发送数据。即，进行正常大小的数据(Normalsizedata)发送，然后结束处理。依据以上实施方式6的变形例1，在上述实施方式1的效果之外，还可获得以下效果。可避免对IP连接接入网络执行不必要的手续。能够避免因重复执行建立EPS承载的处理，而导致被PDN方作为非法请求拒绝连接的风险。此外，可以避免不必要的无线承载设定，防止控制处理的重复以及通信系统因控制处理重复而不稳定的情况。这样，便可以通过安全的步骤切换通信承载，并且可以降低外部网络动作对通信造成的影响。实施方式6变形例2.以下，针对实施方式6的变形例2所解决的课题，进行说明。在实施方式6的connection-lite下的传送中，假设用于每次传送数据量较小的情况。然而，如果设想通过IP分组进行传送，则例如RFC2460等提出的IPv6(InternetProtocolVersion6)的IP报头是40字节(byte)，即使经过PDCP中的报头压缩，相对于发送数据量的报头开销仍然不小。在上述状态中，设想的是UE的IP地址的分配为1个，可视为与UE的ID等价，因此至少UE的IP地址信息传送浪费了无线资源。此外，由于作为UE通信对象的装置的IP地址被限定，因此通信对象装置的IP地址的信息传送也可能浪费无线资源。为解决上述问题，采取以下措施。在connection-lite的Uu点传送中，不传送IP报头的网络地址信息等，而将IP报头中表示上位协议的要素以及发送方地址等进行简化，构建为另外的报头。作为简化IP报头、重新构建其他报头的实体的具体例，例如有MME等。作为进行简化、重新构建其他报头的简化对象参数的具体例，揭示以下(1)～(7)的7种。(1)源地址(SourceAddress)。由于设想UE的IP地址的分配为1个，因此可通过简化重新构建。此外，由于设想成为UE的通信对象的装置也被限定，因此可通过简化重新构建。(2)目标地址(DestinationAddress)。由于设想UE的IP地址的分配为1个，因此可通过简化重新构建。此外，由于设想成为UE的通信对象的装置也被限定，因此可通过简化重新构建。(3)版本。由于在3GPP中规定的通信方式中使用的IP报头的版本以静态方式决定，因此即使进行简化也可毫无问题地进行通信。(4)通信级别。由于在进行EPS承载设定(有时也称为“呼叫设定”)时是以静态方式决定，因此即使进行简化也可毫无问题地进行通信。(5)跳数限制。在移动终端结束时，及在移动终端之前不再访问节点时，即使进行简化也可毫无问题地进行通信。(6)流标签(FlowLabel)。(7)上述(1)～(6)的组合。本变形例可以与上述实施方式6以及实施方式6的变形例1组合使用。通过以上实施方式6的变形例2，可获得以下效果。可削减IP地址部分的传送量，减少所使用的无线资源。实施方式6变形例3.以下，针对实施方式6的变形例3所解决的课题，进行说明。在非专利文献15所提出的准连接(connection-lite)状态下的传送中，是在设定无线区间的连接(RRCConnection)后进行数据传送的结构。然而，设想以小数据进行1个分组的传送时，执行无线区间的连接对于通信终端装置的功耗以及无线资源的影响就会很大。为解决上述问题，可采取与上述实施方式1的变形例4同样的以下措施。在准连接(connection-lite)状态，使用上述实施方式1的变形例4传送小数据。在RRC待机状态(RRC_IDLE)下向eNB发送小数据。在随机接入(RandomAccess)处理中发送小数据。具体内容与上述实施方式1的变形例4相同，因此省略说明。本变形例可以与上述实施方式6、实施方式6的变形例1以及实施方式6的变形例2组合使用。通过以上实施方式6的变形例3，可获得以下效果。由于不设定RRC连接(RRCConnection)，因此可省略该步骤，能够减少通信终端装置的功耗以及无线资源。实施方式6变形例4.实施方式6的变形例4所要解决的课题与上述实施方式6的变形例3相同。为解决上述问题，可采取与实施方式1的变形例5同样的以下措施。在准连接(connection-lite)状态，使用上述实施方式1的变形例5传送小数据。在RRC待机状态(RRC_IDLE)下向eNB发送小数据。在寻呼处理中发送小数据。具体内容与上述实施方式1的变形例5相同，因此省略说明。本变形例可以与上述实施方式6、实施方式6的变形例1、实施方式6的变形例2以及实施方式6的变形例3组合使用。通过以上实施方式6的变形例4，可获得以下效果。由于不设定RRC连接(RRCConnection)，因此可省略该步骤，能够减少通信终端装置的功耗以及无线资源。实施方式6变形例5.以下，针对实施方式6的变形例5所解决的课题，进行说明。实施方式6及其变形例1～4中，使用UE与eNB的EMC(RRC)连接状态时，可能会产生上述实施方式2中提出的UE与eNB之间状态不一致的问题。为解决上述问题，与上述实施方式2同样，在上述实施方式6及其变形例1～3中追加以下功能，即在RRC_CONNECTED状态下，定期发送“uu-keep-alive”，并将其状态通知给网络。具体内容与上述实施方式2相同，因此省略说明。本变形例可以与上述实施方式6、实施方式6的变形例1、实施方式6的变形例2、实施方式6的变形例3以及实施方式6的变形例4组合使用。通过以上实施方式6的变形例4，可获得以下效果。可以减少UE与eNB之间状态不一致的现象，因此可以减轻对系统资源的影响。实施方式7.实施方式7所要解决的课题与实施方式6的课题基本相同。非专利文献15及非专利文献16等提出的解决措施以及上述实施方式6的解决措施需要通过传送数据，对准连接(connection-lite)的结构以及面向连接(connection-oriented)的结构进行切换。然而，上述方法中，切换结构时，需要进行承载的设置等，从而会产生信令处理增多的问题以及数据传送延迟的问题。图57及图58是表示用于说明实施方式7的课题的次序的图。图57与图58在边界线BL22的位置上相连。图57及图58示出定期进行较小规模数据收发的应用的次序。图57与图58所示的次序与图27～图29所示的次序类似，因此相同的步骤被赋予相同的步骤编号，省略相同的说明。在步骤ST11107中，UE中用于测量RRC层级中数据未发送期间的数据监控定时器结束，进入步骤ST11109。在步骤ST11108中，eNB中用于测量RRC层级中数据未发送期间的数据监控定时器结束，进入步骤ST11110。本定时器结束时，便可推定对象UE的RRC状态已进入IDLE。在步骤ST11109中，UE变为RRC_IDLE状态。并且变为ECM_IDLE状态。在步骤ST11110中，eNB变为RRC_IDLE状态，进入步骤ST11111。在步骤ST11111中，启动S1释放处理A(S1ReleaseProcedureA)。具体内容与图29的步骤ST5134的处理相同，因此省略说明。步骤ST11111的处理结束后，在步骤ST11112中，MME变为ECM_IDLE状态。步骤ST11111的S1释放处理A结束后，在步骤ST11113中，UE的应用向NAS发出数据发送请求，从而发送数据被发送。在步骤ST11114中，启动服务请求处理A(ServiceRequestProcedureA)。具体内容与图27的步骤ST5105的处理相同，因此省略说明。在步骤ST11115中，使用步骤ST11114中建立的EPS承载(EPSBearer)，从UE经由P-GW，向应用服务器发送数据。在步骤ST11116中，UE中用于测量RRC层级中数据未发送期间的数据监控定时器结束，进入步骤ST11118。在步骤ST11117中，eNB中用于测量RRC层级中数据未发送期间的数据监控定时器结束，进入步骤ST11119。在步骤ST11118中，UE变为RRC_IDLE状态。并且变为ECM_IDLE状态。在步骤ST11119中，eNB变为RRC_IDLE状态。并且变为ECM_IDLE状态，进入步骤ST11120。在步骤ST11120中，启动S1释放处理A(S1ReleaseProcedureA)。具体内容与图29的步骤ST5134的处理相同，因此省略说明。步骤ST11120的处理结束后，在步骤ST11121中，MME变为ECM_IDLE状态。在步骤ST11122中，UE的应用向NAS提出数据发送请求，从而发送数据被发送。在步骤ST11123中，启动服务请求处理A(ServiceRequestProcedureA)。具体内容与图27的步骤ST5105的处理相同，因此省略说明。由此，在每次发送小规模数据时，将重复步骤ST11114的服务请求处理A和步骤ST11120的服务请求处理A。这样，就会需要较多的步骤，与之相随的，会消耗网络资源，增加通信终端装置的功耗。为解决上述问题，采取以下措施。不使RRC状态与NAS状态联动地迁移。以下，NAS状态也称为ECM状态。下面使用图57和图58具体说明，与步骤ST11109不同，即使UE迁移到了RRC_IDLE状态，也不与该迁移联动地使UE迁移到ECM_IDLE状态。在UE中，即使RRC连接(RRCConnection)被释放，也不向ECM_IDLE状态迁移，仍然维持ECM_CONNECTED状态。此外，与步骤ST11110不同，即使eNB迁移到RRC_IDLE状态，也不与该迁移联动地使eNB启动S1释放处理(S1ReleaseProcedure)。换言之，即使eNB迁移至RRC_IDLE，MME也不会与该迁移联动地迁移到ECM_IDLE状态。也就是说，即使eNB迁移至RRC_IDLE状态，也不启动S1释放处理(S1ReleaserProcedure)，MME仍然维持ECM_CONNECTED状态。在设定了用于U-plane的E-RAB(E-UTRANRadioAccessBearer)状态下，可得到以下架构：即在维持NAS层级(S1层级)的连接状态下，仅释放或建立无线区间的连接。这样，便可在维持上位承载，例如S1承载等的情况下，释放无线区间的资源。由于实现了释放无线区间资源的目的，因此便可解决需要重设上位承载的问题。通常，在UE中，RRC的状态与ECM的状态会联动地发生迁移。ECM_CONNECTED状态的UE在RRC连接(RRCConnection)被释放时，就会进入ECM_IDLE状态。RRC连接被释放后，就成为RRC_IDLE状态。因此，由于RRC连接的释放，就会从RRC_CONNECTED迁移到RRC_IDLE，与之联动地，从ECM_CONNECTED迁移到ECM_IDLE(参考非专利文献13第4.6.4章)。在通常的网络中，RRC的状态与ECM的状态会联动地发生迁移。ECM_CONNECTED状态下的eNB，在假设成为对象的UE的RRC状态进入RRC_IDLE时，将启动S1释放处理(S1ReleaseProcedure)。S1连接被释放后，就会从ECM_CONNECTED迁移到ECM_IDLE。因此，当迁移至RRC_IDLE后，与之联动地，S1连接被释放，从ECM_CONNECTED迁移到ECM_IDLE(参考非专利文献13第4.6.4章)。作为对使正常的RRC状态与ECM状态联动地迁移还是如本实施方式提出的解决措施，不使RRC状态与ECM状态联动地迁移进行判断的主体，例如有UE。上述判断有时也称为“状态迁移方法判断”。作为状态迁移方法判断的具体例，揭示以下(1)、(2)的两种。(1)UE根据提出接入请求的应用进行判断。(1-1)判断是否是定期发送较小规模数据的应用。当判断是定期发送较小规模数据的应用时，决定不使RRC状态与ECM状态联动地迁移。当判断不是定期发送较小规模数据的应用时，决定使正常的RRC状态与ECM状态联动地迁移。在现有技术中，定期发送较小规模数据的应用会重复进行无线承载的释放与建立。也就是在RRC_IDLE状态与RRC_CONNECTED状态之间重复迁移。与之联动地，会在ECM_IDLE状态和ECM_CONNECTED状态之间重复迁移。因此，通过使用本实施方式，可获得明显简化处理步骤的效果。(1-2)判断是否是请求发送keep-alive分组的应用。当判断是请求发送keep-alive分组的应用时，决定不使RRC状态与ECM状态联动地迁移。当判断不是请求发送keep-alive分组的应用时，决定使正常的RRC状态与ECM状态联动地迁移。在现有技术中，请求发送keep-alive分组的应用会重复进行无线承载的释放与建立。也就是在RRC_IDLE状态与RRC_CONNECTED状态之间重复迁移。与之联动地，会在ECM_IDLE状态和ECM_CONNECTED状态之间重复迁移。因此，通过使用本实施方式，可获得明显简化处理步骤的效果。(2)UE判断是否是重复发送。UE也可判断是否是在小于阈值的周期内的重复发送。重复发送的具体例有“Uukeepaliveind”、UE监控用消息、周期性测量报告、周期性TAU等。当判断是重复发送时，决定不使RRC状态与ECM状态联动地迁移。当判断不是重复发送时，决定使正常的RRC状态与ECM状态联动地迁移。在现有技术中，周期性重复发送会重复进行无线承载的释放与建立。也就是在RRC_IDLE状态与RRC_CONNECTED状态之间重复迁移。与之联动地，会在ECM_IDLE状态和ECM_CONNECTED状态之间重复迁移。因此，通过使用本实施方式，可获得明显简化处理步骤的效果。UE将状态迁移判断的结果通知给网络方。作为将状态迁移判断结果通知给网络方的方法的具体例，有以下(1)、(2)的两种。(1)新设信号或消息。(1-1)新设RRC信号或RRC消息。(1-2)新设NAS信号或NAS消息。(1-3)新设RRC信号和NAS信号这两者。(2)使用现有的信号或消息。本具体例(2)无需设置新的信号，这一点比具体例(1)更有效。利用本具体例(2)，可以避免通信系统的复杂化。作为映射到新信号的参数的具体例，有以下(1)～(3)的3种。(1)状态迁移判断的结果。可以仅在判断为不使RRC的状态与ECM状态联动地迁移时进行通知。在以下说明中，有时将判断为不使RRC的状态与ECM状态联动地迁移的情况称为“RRC独立”，并将追加的参数称为“RRC独立”。(2)UE的识别符。具体而言，可以是UE-ID、IMSI。(3)上述(1)、(2)的组合。然后，作为使用现有RRC信号时的具体例，如使用RRC连接请求(RRCConnectionRequest)消息。在以下说明中，有时将判断为不使RRC的状态与ECM状态联动地迁移的情况称为“RRC独立”，并将追加的参数称为“RRC独立”。作为需要追加到现有RRC信令的参数的具体例，如状态迁移判断的结果等。然后，作为使用现有NAS信号时的具体例，如使用服务请求(ServiceRequest)消息。作为需要追加到现有NAS信令的参数的具体例，如状态迁移判断的结果等。可在现有RRC信号、现有NAS信号的双方追加参数。获得状态迁移判断结果的eNB，在建立S1承载时，将状态迁移判断的结果与该S1承载相关联地进行储存。作为具体例，例如在建立S1承载时，对于该S1承载是使正常的RRC状态与ECM状态联动地迁移的承载还是不使RRC的状态与ECM状态联动地迁移的承载进行储存。或者对于该S1承载与RRC承载是进行联动管理还是对该S1承载与RRC承载进行独立管理进行储存。或者，对于在RRC承载被释放时是开始S1承载的释放处理(S1ReleaseProcedure)，还是在RRC承载被释放时不开始S1承载的释放处理进行储存。eNB可基于储存的状态迁移判断结果，进行以下动作。在状态迁移判断的结果为使RRC的状态与ECM的状态联动地迁移时，对规定期间内有无RRC数据收发进行判断。以下将规定期间称为“RRC数据监控定时器(eNB)”。在RRC数据监控定时器(eNB)结束之前，有RRC数据收发时，eNB维持RRC_CONNECTED状态。并且维持ECM_CONNECTED状态。另一方面，在RRC数据监控定时器(eNB)结束之前，没有RRC数据收发时，eNB迁移至RRC_CONECTED状态。并且迁移至ECM_IDLE状态。即，启动S1释放处理(S1ReleaseProcedure)。在状态迁移判断的结果为不使RRC的状态与ECM的状态联动地迁移时，对规定期间内有无RRC数据收发进行判断。并且，另外对规定期间内有无NAS数据收发进行判断。以下将规定期间称为“NAS数据监控定时器(eNB)”。在RRC数据监控定时器(eNB)结束之前，有RRC数据收发时，eNB维持RRC_CONNECTED状态。另一方面，在RRC数据监控定时器(eNB)结束之前，没有RRC数据收发时，eNB迁移至RRC_CONECTED状态。即，释放无线承载的资源。作为无线承载的资源具体例，例如有对于该UE的调度请求资源等。但是，不迁移至ECM_IDLE状态。即，不启动S1释放处理(S1ReleaseProcedure)。在NAS数据监控定时器(eNB)结束之前，有NAS数据收发时，eNB维持ECM_CONNECTED状态。另一方面，在NAS数据监控定时器(eNB)结束之前，没有NAS数据收发时，eNB迁移至ECM_IDLE状态。即，释放S1承载、EPS承载的资源。也可启动S1释放处理(S1ReleaseProcedure)。UE也可对状态迁移判断的结果进行储存。状态迁移判断的结果可以与该S1承载相关联地进行储存。在状态迁移判断的结果为正常地使RRC的状态与ECM的状态联动地迁移时，对规定期间内有无RRC数据收发进行判断。以下将规定期间称为“RRC数据监控定时器(UE)”。在RRC数据监控定时器(UE)结束之前，有RRC数据收发时，UE维持RRC_CONNECTED状态。并且维持ECM_CONNECTED状态。另一方面，在RRC数据监控定时器(UE)结束之前，没有RRC数据收发时，UE迁移至RRC_CONECTED状态。并且迁移至ECM_IDLE状态。在状态迁移判断的结果为不使RRC的状态与ECM的状态联动地迁移时，对规定期间内有无RRC数据收发进行判断。并且，另外对规定期间内有无NAS数据收发进行判断。以下将规定期间称为“NAS数据监控定时器(UE)”。在RRC数据监控定时器(UE)结束之前，有RRC数据收发时，UE维持RRC_CONNECTED状态。另一方面，在RRC数据监控定时器(UE)结束之前，没有RRC数据收发时，UE迁移至RRC_CONECTED状态。但是，不迁移至ECM_IDLE状态。在NAS数据监控定时器(UE)结束之前，有NAS数据收发时，UE维持ECM_CONNECTED状态。另一方面，在NAS数据监控定时器(UE)结束之前，没有NAS数据收发时，UE迁移至ECM_IDLE状态。NAS数据监控定时器(eNB)与NAS数据监控定时器(UE)可以相同。有时也将两者相同时的定时器称为“NAS数据监控定时器”。其可获得减少UE与eNB状态不一致的期间的效果。作为NAS数据监控定时器的决定主体的具体例，例如有UE及eNB。作为NAS数据监控定时器的决定方法的具体例，有以下(1)～(3)的3种。(1)可依据应用来决定。(1-1)可根据应用请求的QoS、QCI、承载信息等决定。(1-2)应用发送keep-alive分组时，比其周期更长的值。在NAS数据监控定时器结束之前，会发送keep-alive分组。因此，在应用继续的期间，UE与eNB之间可维持ECM_CONNECTED状态。(2)S1资源状况。S1资源不足时，可设定较短，S1资源没有不足时，可设定较长。(3)以静态方式决定。这样，便可获得在UE与eNB之间无需进行通知的效果。作为UE决定NAS数据监控定时器后向eNB通知的方法的具体例，有以下(1)～(4)的4种。(1)通过TAU处理进行通知。具体例如通过TAU请求(TAURequest)等进行通知。(2)通过附着处理进行通知。具体例如，通过附着请求(AttachRequest)、RRC连接重配置完成(RRCConnectionReconfigurationComplete)等进行通知。(3)通过RRC连接设置处理(RRCConnectionSetupProcedure)进行通知。具体例如，通过RRC连接设置请求(RRCConnectionSetupRequest)等进行通知。(4)通过服务请求处理(ServiceRequestProcedure)进行通知。具体例如，通过服务请求(ServiceRequest)、RRC连接重配置完成(RRCConnectionReconfigurationComplete)等进行通知。作为eNB决定NAS数据监控定时器后向UE通知的方法的具体例，有以下(1)～(6)的6种。(1)利用广播信息进行通知。(2)利用专用信息进行通知。(3)通过TAU处理进行通知。具体例如通过TAU接受(TAUAccept)等进行通知。(4)通过附着处理进行通知。具体例如，利用附着接受(AttachAccept)、RRC连接重配置(RRCConnectionReconfiguration)等进行通知。(5)通过RRC连接设置处理(RRCConnectionSetupProcedure)进行通知。具体例如，通过RRC连接设置(RRCConnectionSetup)等进行通知。(6)通过服务请求处理(ServiceRequestProcedure)进行通知。具体例如，通过RRC连接重配置(RRCConnectionReconfiguration)等进行通知。RRC数据监控定时器(eNB)与RRC数据监控定时器(UE)可以相同。将两者相同时的定时器称为“RRC数据监控定时器”。其可获得减少UE与eNB状态不一致的期间的效果。作为RRC数据监控定时器的决定主体的具体例，例如有UE及eNB。作为RRC数据监控定时器的决定方法的具体例，有以下(1)、(2)的两种。(1)无线资源状况。无线资源不足时，可设定较短，无线资源没有不足时，可设定较长。(2)以静态方式决定。这样，便可获得在UE与eNB之间无需进行通知的效果。作为UE决定RRC数据监控定时器后向eNB通知的方法的具体例，有以下(1)～(3)的3种。(1)通过TAU处理进行通知。具体例如通过TAU请求(TAURequest)等进行通知。(2)通过附着处理进行通知。具体例如，通过附着请求(AttachRequest)、RRC连接重配置完成(RRCConnectionReconfigurationComplete)等进行通知。(3)通过RRC连接设置处理(RRCConnectionSetupProcedure)进行通知。具体例如，通过RRC连接设置请求(RRCConnectionSetupRequest)等进行通知。作为eNB决定RRC数据监控定时器后向UE通知的方法的具体例，有以下(1)～(5)的5种。(1)利用广播信息进行通知。(2)利用专用信息进行通知。(3)通过TAU处理进行通知。具体例如通过TAU接受(TAUAccept)等进行通知。(4)通过附着处理进行通知。具体例如，利用附着接受(AttachAccept)、RRC连接重配置(RRCConnectionReconfiguration)等进行通知。(5)通过RRC连接设置处理(RRCConnectionSetupProcedure)进行通知。具体例如，通过RRC连接设置(RRCConnectionSetup)等进行通知。在RRC_IDLE状态下应用提出接入请求时，UE可对是否还维持着ECM_CONNECTED进行判断。或者，也可以判断是否存在仍在维持的S1承载。判断为没有维持ECM_CONNECTED时，或者不存在仍然维持的S1承载时，对于该接入请求，可执行上述状态迁移方法判断。判断为还维持着ECM_CONNECTED时，或者存在仍然维持的S1承载时，对是否是能够使用与正在维持的ECM_CONNECTED相对应的EPS承载发送的数据进行判断。也可对是否是建立与ECM_CONNECTED相对应的EPS承载时相同的应用提出的发送请求进行判断。判断是无法用EPS承载发送的数据时，可对该接入请求执行上述状态迁移方法判断。判断是可以用EPS承载发送的数据时，请求建立RRC连接。此时，将正在维持ECM_CONNECTED的内容一并通知。作为具体例，例如启动RRC连接设置处理(RRCConnectionSetupProcedure)，同时一并通知正在维持ECM_CONNECTED的内容。此外，也可不启动服务请求处理(ServiceRequestProcedure)。通知方法的具体例说明如下。使用现有的RRC信号或RRC消息。具体例如使用RRC连接请求(RRCConnectionRequest)。由于与现有RRC连接设置处理(RRCConnectionSetupProcedure)中使用的消息同样，因此可避免通信系统复杂化。作为需要追加到现有RRC信令的参数的具体例，有以下(1)～(3)的3种。(1)使用现有S1承载的内容，正在维持ECM_CONNECTED的内容等。不需要建立S1承载的内容。(2)可确定现有S1承载的信息。例如索引号等。(3)上述(1)、(2)的组合。eNB接收到表示在RRC连接设置处理(RRCConnectionSetupProcedure)中使用了现有S1承载等的通知后，不启动S1承载的设置。此外，也可识别为没有从UE发来服务请求(ServiceRequest)通知。使RRC连接(RRCconnection)与S1承载关联，向UE发送RRC连接设置(RRCConnectionSetup)。可以只在RRC连接手续中发送数据，而不进行S1承载的设置。当RRC状态与ECM状态不联动地迁移时，UE从应用接收到服务切断请求或服务释放请求后，可以将S1承载释放请求通知给eNB。或者通知NAS层级的资源释放请求。作为通知方法的具体例揭示以下(1)、(2)的两种。(1)新设RRC信号或RRC消息。以下也称为“NAS释放请求”。(2)新设NAS信号或NAS消息。以下也称为“NAS释放请求”。作为映射到新信号的参数的具体例，有以下(1)～(4)的4种。(1)表示是S1承载释放请求的内容、是NAS层级的资源释放请求的内容等，请求向ECM_IDLE迁移的内容等。(2)UE的识别符。具体而言，可以是UE-ID、IMSI。(3)可确定现有S1承载的信息。例如索引号等。(4)上述(1)～(3)的组合。接下来，使用图59～图61，说明实施方式7中通信系统的次序的具体例。图59～图61是表示实施方式7中通信系统的次序的一个示例的图。图59与图60在边界线BL23的位置上相连。图60与图61在边界线BL24的位置上相连。图59～图61所示的次序与图27～图29以及图44～图47所示的次序类似，因此相同的步骤被赋予相同的步骤编号，省略相同的说明。UE的NAS在步骤ST5104中接收到接入请求(AccessRequest)后，执行状态迁移方法判断。状态迁移方法判断的结果为RRC状态与ECM的状态不联动地迁移，即“RRC独立”时，在步骤ST11203中，启动服务请求处理(ServiceRequestProcedure)(RRC独立)。步骤ST11203的服务请求处理(RRC独立)包含步骤ST11204～步骤ST9147的处理。步骤ST11204中，UE的NAS向AS(AccessStratum)发送服务请求(ServiceRequest)消息。UE的NAS也可以通知RRC层。步骤ST11204的服务请求消息中可含有状态迁移判断的结果。UE的RRC层在步骤ST11204中接收到服务请求消息，该服务请求消息中包含了表示RRC状态与ECM状态不联动地迁移的信息(RRC独立)时，在步骤ST11205中，启动RRC连接设置处理(RRCConnectionSetupProcedure)(RRC独立)。步骤ST11205的RRC连接设置处理(RRC独立)包含步骤ST11206～步骤ST11208的处理。在步骤ST11206中，UE的RRC层向eNB发送RRC连接设置请求(RRCConnectionSetupRequest)消息。RRC连接设置请求消息中可包含表示RRC状态与ECM状态不联动地迁移的信息(RRC独立)。eNB在步骤ST11206中接收到RRC连接设置请求消息后，在步骤ST11207中，向UE的RRC层发送RRC连接设置(RRCConnectionSetup)消息。RRC连接设置消息中可包含表示RRC状态与ECM状态不联动地迁移的信息。UE在步骤ST11207中接收到RRC连接设置消息后，在步骤ST11208中，向eNB发送RRC连接设置完成(RRCConnectionSetupComplete)消息。RRC连接设置完成消息中可包含表示RRC状态与ECM状态不联动地迁移的信息。步骤ST11205的RRC连接设置处理(RRC独立)完成后，步骤ST11209中，UE便成为RRC_CONNECTED状态。并且，UE成为ECM_CONNECTED状态。同样，在步骤ST11210中，eNB将该UE的RRC状态设想为RRC_CONNECTED状态。以下简称为“eNB成为RRC_CONNECTED状态”。步骤ST11211中，UE的RRC层向eNB发送服务请求(ServiceRequest)消息。服务请求消息中可包含表示RRC状态与ECM状态不联动地迁移的信息。eNB在步骤ST11211中接收到服务请求消息后，在步骤ST11212中，将服务请求(ServiceRequest)消息发送给MME。服务请求消息中可包含表示RRC状态与ECM状态不联动地迁移的信息。在步骤ST11213中，MME利用HSS的信息，进行UE的认证(authentication)以及安全(security)控制处理。在步骤ST11214中，MME向eNB发送初始上下文设置请求(InitialContextSetupRequest)消息。初始上下文设置请求消息中可包含表示RRC状态与ECM状态不联动地迁移的信息。eNB在步骤ST11214中接收到初始上下文设置请求消息后，在步骤ST11215中，启动无线承载建立处理(RadioBearerEstablishmentProcedure)(RRC独立)。步骤ST11215的无线承载建立处理(RRC独立)包含步骤ST11216～步骤ST11217的处理。在步骤ST11216中，eNB将RRC连接重配置(RRCConnectionReconfiguration)消息发送给UE。RRC连接重配置消息中可包含表示RRC状态与ECM状态不联动地迁移的信息。UE在步骤ST11216中接收到RRC连接重配置消息后,在步骤ST11217中，向eNB发送RRC连接重配置完成(RRCConnectionReconfigurationComplete)消息。RRC连接重配置完成消息中可包含表示RRC状态与ECM状态不联动地迁移的信息。eNB在步骤ST11217中接收到RRC连接重配置完成消息后，在步骤ST11218中，将初始上下文设置完成(InitialContextSetupComplete)消息发送给MME。初始上下文设置完成消息中可包含表示RRC状态与ECM状态不联动地迁移的信息。接收到修改承载响应消息的MME在步骤ST11225，相对于该UE进入ECM_CONNECTED状态。也可以在与该UE之间完成S1连接的建立后，MME相对于该UE进入ECM_CONNECTED状态。完成与该UE之间的S1连接建立是通过MME接收到步骤ST11218中初始上下文设置完成消息来识别。步骤ST11203中，通过服务请求处理(RRC独立)的完成，在步骤ST11229中，UE便可经由eNB、MME、S-GW、P-GW，向应用服务器(APPServer)发送数据。在图61的步骤ST11230中，UE中用于测量RRC层级中数据未发送期间的数据监控定时器结束。UE判断当前的RRC连接是否是RRC状态与ECM状态不联动地迁移(RRC独立)的承载。当判断是RRC状态与ECM状态不联动地迁移(RRC独立)的承载时，仅RRC进入IDLE状态，ECM维持CONNECTED。当判断不是RRC状态与ECM不联动地迁移(RRC独立)的承载时，RRC和ECM都进入IDLE状态。在本次序中，由于是RRC独立承载，因此进入步骤ST11232及步骤ST11233。在步骤ST11231中，eNB中用于测量RRC层级数据中未发送期间的数据监控定时器结束，进入步骤ST11234。上述定时器结束时，便可设想或推定对象UE的RRC状态已进入IDLE。在步骤ST11232中，UE变为RRC_IDLE状态。在步骤ST11233中，UE可参考所储存的状态迁移判断结果。状态迁移判断结果是使正常的RRC状态与ECM状态联动地迁移时，UE使ECM的状态与RRC状态联动地迁移。即，使ECM状态迁移至ECM_IDLE。另一方面，状态迁移判断结果是不使RRC状态与ECM状态联动地迁移时，UE不使ECM的状态与RRC状态联动地迁移，而维持ECM_CONNECTED状态。本动作例中，在步骤ST11233中，UE维持ECM_CONNECTED状态。在步骤ST11234中，eNB变为RRC_IDLE状态，进入步骤ST11235。在步骤ST11235中，eNB可参考所储存的状态迁移判断结果。状态迁移判断结果为不使RRC状态与ECM状态联动地迁移时，维持ECM_CONNECTED状态。即，不启动S1释放处理A(S1ReleaseProcedureA)。状态迁移判断结果是使正常的RRC状态与ECM状态联动地迁移时，ECM状态也进入IDLE。即，进入步骤ST11236，启动S1释放处理A(S1ReleaseProcedureA)。S1释放处理A的具体内容与图27的步骤ST5105的处理相同，因此省略说明。此外，在图59～图61中，省略了之后处理的说明，记为“结束”。步骤ST11235中，判断状态迁移判断结果为不使RRC状态与ECM状态联动地迁移时，由于不启动S1释放处理A，因此在步骤ST11237中，维持ECM_CONNECTED。在步骤ST11238中，UE的应用向NAS提出数据发送请求，从而发送数据被发送。UE的NAS可判断是否维持着ECM_CONNECTED。没有维持ECM_CONNECTED时，启动正常的服务请求处理A(ServiceRequestProcedureA)。正常的服务请求处理A的具体内容与步骤ST11114的处理相同，因此省略说明。维持着ECM_CONNECTED时，判断是否是能通过与维持着的ECM_CONNECTED相对应的EPS承载(EPSBearer)进行发送的数据。换言之，也可对是否是与建立对应于ECM_CONNECTED的EPS承载(EPSBearer)时相同的应用提出的发送请求进行判断。如果是无法通过EPS承载发送的数据，则启动正常的服务请求处理A。正常的服务请求处理A的具体内容与步骤ST11114的处理相同，因此省略说明。如果是能够通过EPS承载发送的数据，则进入步骤ST11239。在步骤ST11239中，UE启动RRC连接设置处理。此时，将一并通知正在维持ECM_CONNECTED的内容(以下有时称为“现有S1承载”)。此外，也可通知作为现有S1承载的能够确定的信息。启动RRC连接设置处理(RRCConnectionSetupProcedure)(现有S1承载)。步骤ST11239的RRC连接设置处理(现有S1承载)包含步骤ST11240～步骤ST11242的处理。步骤ST11240中，UE的RRC层向eNB发送RRC连接请求(RRCConnectionRequest)消息。RRC连接请求消息中，可包含表示正在维持ECM_CONNECTED的内容、确定符合对应连接的S1承载的信息。eNB在步骤ST11240中接收到RRC连接请求消息后，在步骤ST11241中向UE的RRC层发送RRC连接设置(RRCConnectionSetup)消息。RRC连接设置消息中，可包含表示正在维持ECM_CONNECTED的内容、确定符合对应连接的S1承载的信息。UE在步骤ST11241中接收到RRC连接设置消息后，在步骤ST11242中，向eNB发送RRC连接设置完成(RRCConnectionSetupComplete)消息。RRC连接设置完成消息中，可包含表示正在维持ECM_CONNECTED的内容、确定符合对应连接的S1承载的信息。在步骤ST11243中，使用对应的连接，从UE经由P-GW，向应用服务器发送数据。具体而言，使用对应的EPS承载(EPSbearer)发送数据。在步骤ST11244中，UE中用于测量RRC层级中数据未发送期间的数据监控定时器结束。步骤ST11244处理的具体内容与步骤ST11230的处理相同，因此省略说明。在步骤ST11245中，eNB中用于测量RRC层级中数据未发送期间的数据监控定时器结束。步骤ST11245处理的具体内容与步骤ST11231的处理相同，因此省略说明。在步骤ST11247中，UE变为RRC_IDLE状态。在步骤ST11248中，eNB成为RRC_IDLE状态，执行与步骤ST11235相同的处理。通过与步骤ST11235相同的处理，当状态迁移判断结果是RRC状态与ECM状态不联动地迁移时，不启动S1释放处理A，因此维持ECM_CONNECTED。在步骤ST11246中，UE的应用向NAS提出数据发送请求，从而发送数据被发送。步骤ST11246处理的具体内容与步骤ST11238的处理相同，因此省略说明。在步骤ST11249中，UE启动RRC连接设置处理(RRCConnectionSetupProcedure)(现有S1承载)。步骤ST11249处理的具体内容与步骤ST11239的处理相同，因此省略说明。在步骤ST11250中，使用对应的连接，从UE经由P-GW，向应用服务器发送数据。具体而言，使用对应的EPS承载(EPSbearer)发送数据。以下重复上述处理。接下来，使用图62及图63，说明实施方式7中通信系统的次序的具体例。图62及图63是表示实施方式7中通信系统的次序的其他示例的图。图62与图63在边界线BL25的位置上相连。图62及图63中，示出通过UE起点的释放手续释放S1承载的次序，该S1承载是状态迁移判断结果为使RRC状态与ECM状态不联动地迁移而建立的承载。图62及图63所示的次序与图27～图29以及图59～图61所示的次序类似，因此相同的步骤被赋予相同的步骤编号，省略相同的说明。在图63的步骤ST11323中，UE的应用向UE的NAS发送服务切断请求或服务释放请求。UE的NAS可判断是否维持着ECM_CONNECTED。当判断为没有维持ECM_CONNECTED时，执行使UE的状态迁移至RRC_IDLE和ECM_IDLE的处理。当判断为维持着ECM_CONNECTED时，可进入步骤ST11324。在步骤ST11324中，UE的NAS向AS(AccessStratum)提出NAS层级(S1承载)的连接释放请求。具体而言，即请求发送NAS释放请求(NASReleaseRequest)消息。UE的NAS也可以通知RRC层。在步骤ST11325中，UE进行RRC连接设置处理(RRCConnectionSetupProcedure)。RRC连接设置处理的详细情况与步骤ST9104相同，因此省略说明。或者，在步骤ST11325中，UE启动RRC连接设置处理(RRCConnectionSetupProcedure)(现有S1承载)。RRC连接设置处理(现有S1承载)的详细情况与步骤ST11239的处理相同，因此省略说明。在步骤ST11326中，UE向eNB发送NAS层级(S1承载)的连接释放请求。具体而言，即发送NAS释放请求(NASReleaseRequest)消息。NAS释放请求消息中，可包含确定符合对应连接的S1承载的信息。eNB在步骤ST11326中接收到NAS释放请求消息后，在步骤ST11327中，将NAS释放请求(NASReleaseRequest)消息发送给MME。NAS释放请求消息中，可包含确定符合对应连接的S1承载的信息。MME在步骤ST11327中接收到NAS释放请求消息后，在步骤ST11328中，启动释放该S1承载的处理。具体而言即启动S1释放处理B(S1ReleaseProcedureB)。S1释放处理B与S1释放处理A的差别在于，在S1释放处理B中，不存在eNB起点的UE上下文释放请求(UEContextReleaseRequest)。步骤ST11328的S1释放处理B包含步骤ST11329～步骤ST11333的处理。在步骤ST11329中，MME将接入承载释放请求(ReleaseAccessBearersRequest)消息发送给S-GW。接入承载释放请求消息中，可包含确定符合对应连接的S1承载的信息。或者，也可包含表示释放RRC状态与ECM状态不联动地迁移的S1承载的信息。S-GW在步骤ST11329中接收到接入承载释放请求消息后，在步骤ST11330中，将接入承载释放响应(ReleaseAccessBearersResponse)消息通知给MME。接入承载释放响应消息中，可包含确定符合对应连接的S1承载的信息。或者，也可包含表示释放RRC状态与ECM状态不联动地迁移的S1承载的信息。MME在步骤ST11330中接收到接入承载释放响应消息后，在步骤ST11331中，将UE上下文释放命令(UEContextReleaseCommand)通知给eNB。UE上下文释放命令中，可包含确定符合对应连接的S1承载的信息。或者，也可包含表示释放RRC状态与ECM状态不联动地迁移的S1承载的信息。eNB在步骤ST11331中接收到UE上下文释放命令后，在步骤ST11332中，将RRC连接释放(RRCConnectionRelease)消息通知给UE。在步骤ST11333中，eNB将UE上下文释放完成(UEContextReleaseComplete)消息通知给MME。UE上下文释放完成消息中，可包含确定符合对应连接的S1承载的信息。或者，也可包含表示释放RRC状态与ECM状态不联动地迁移的S1承载的信息。通过这种动作，便可通过针对RRC独立承载而建立的S1承载的定时器进行释放。接下来，使用图64及图65，说明实施方式7中通信系统的次序的具体例。图64及图65是表示实施方式7中通信系统的次序的其他示例的图。图64与图65在边界线BL26的位置上相连。图64及图65中，示出通过基于S1承载的定时器的释放步骤进行释放的次序，该S1承载为使RRC状态与ECM状态不联动地迁移而建立的承载。图64及图65所示的次序与图27～图29以及图59～图61所示的次序类似，因此相同的步骤被赋予相同的步骤编号，省略相同的说明。在图65的步骤ST11423中，UE中用于测量NAS层级中数据未发送期间的数据监控定时器结束。NAS层级中数据未发送期间的测量可只在建立了状态迁移方法判断结果为使RRC状态与ECM状态不联动地迁移的情况下的S1承载时进行。在步骤ST11424中，UE成为ECM_IDLE状态。在步骤ST11425中，eNB中用于测量NAS层级中数据未发送期间的数据监控定时器结束，进入步骤ST11426。上述定时器结束时，便可推定对象UE的ECM状态变为IDLE。NAS层级中数据未发送期间的测量可只在建立了状态迁移方法判断结果为使RRC状态与ECM状态不联动地迁移的情况下的S1承载时进行。在步骤ST11426中，eNB启动S1释放处理A(S1ReleaseProcedureA)。步骤ST11426处理的具体内容与图29的步骤ST5134的处理相同，因此省略说明。步骤ST11426的处理结束后，在步骤ST11428中，MME变成ECM_IDLE状态。通过这样的动作，便可以利用状态迁移方法判断结果为使RRC状态与ECM状态不联动地迁移的情况下的S1承载的定时器进行释放。通过以上实施方式7，可获得以下效果。在维持NAS层级的连接的状态下，可仅释放或建立无线区间的连接。RRC状态的迁移独立于上位承载，例如S1承载的建立，因此可减轻导致利用无线接入网络中系统资源，具体而言即无线资源与通信节点上的处理负荷等的问题，也可减少UE功耗增加的问题。此外，由于不包含上述实施方式6中的S1承载的设置，可仅通过RRC连接进行对应，因此处理步骤更加简化。实施方式7变形例1.以下，针对实施方式7的变形例1所解决的课题，进行说明。在上述实施方式7中，在建立RRC独立承载时，若UE要在RRC_IDLE状态下发送数据，则必须建立RRC连接(RRCConnection)。然而，设想以小数据进行1个分组的传送时，执行无线区间的连接对于通信终端装置的功耗以及无线资源的影响就会很大。为解决上述问题，可采取与上述实施方式1的变形例4同样的以下措施。在准连接(connection-lite)状态，对于小数据，不建立RRC连接(RRCConnection)，而是在随机接入步骤内发送数据。发送步骤与上述实施方式1的变形例4相同。通过上述措施，由于不设定RRC连接(RRCConnection)，因此可省略该步骤，能够减少通信终端装置的功耗以及无线资源。实施方式7变形例2.实施方式7的变形例2所要解决的课题与实施方式7的变形例1相同。为解决上述问题，可采取与上述实施方式1的变形例5同样的以下措施。在准连接(connection-lite)状态，对于小数据，不建立RRC连接(RRCConnection)，而是在寻呼步骤内发送数据。发送步骤与上述实施方式1的变形例5相同。通过上述措施，由于不设定RRC连接(RRCConnection)，因此可省略该步骤，能够减少通信终端装置的功耗以及无线资源。实施方式7变形例3.以下，针对实施方式7的变形例3所解决的课题，进行说明。上述实施方式7及其变形例1、2中，使用UE与eNB的EMC(RRC)连接状态时，可能会产生上述实施方式2中提出的UE与eNB之间状态不一致的问题。为解决上述问题，与上述实施方式2同样，在上述实施方式6及其变形例1～3中追加以下功能，即在RRC_CONNECTED状态下，定期发送“uu-keep-alive”，并将其状态通知给网络。“uu-keep-alive”的发送步骤与上述实施方式2相同。根据本变形例，可以减少UE与eNB之间状态不一致的现象，因此可以减轻对系统资源的影响。以上对本发明进行了详细说明，但上述说明从各方面而言都是例示，本发明并不局限于此。对于尚有未例示的无数变形例，这些变形例都在本发明的范围之内。标号说明71通信终端装置(UE)、72基站装置、72-1eNB、72-2Home-eNB、73MME/S-GW部(MME部)、74HeNBGW。当前第1页1 2 3 当前第1页1 2 3