JP6645660B2 - Relay node device, communication control method, and program - Google Patents

Description

  The present invention relates to a relay node device, a communication control method, and a program, and more particularly, to a relay node device, a communication control method, and a program for transmitting a message.

  In recent years, with the spread of smartphones and the like, IoT (Internet Of Things) services have also been spreading. The IoT service is implemented, for example, using a terminal or the like that performs autonomous communication without user operation. In general, it is known that traffic characteristics are different between a terminal such as a smartphone and a terminal used for an IoT service. For example, an IoT service often transmits a small amount of data compared to a smartphone or the like. Further, the IoT service may have a traffic characteristic that data is transmitted at a predetermined timing during one day.

  As described above, since the general service using a terminal such as a smartphone and the IoT service have different traffic characteristics, the core network providing the general service and the core network providing the IoT service are separated from each other. Operation is under consideration. By separating the core network, it becomes possible to design equipment and the like according to the traffic characteristics of each service.

  Patent Literature 1 discloses a configuration of a gateway device having traffic characteristics suitable for connecting user terminals by distinguishing user terminals having different traffic characteristics. Specifically, the packet distribution control unit of the gateway device determines a transfer destination of the packet based on the MAC address or the domain information of the user terminal included in the packet. Further, the packet distribution control unit changes the IP address of the packet transmission destination to the IP address of the transfer destination gateway device.

JP 2015-43522 A

  In the future, IoT services are expected to spread rapidly, and terminals used for IoT services are expected to increase rapidly. In this case, even if the facilities of the core network that provides the IoT service are increased, the number of terminals used for the IoT service is rapidly increased, so that the core network that provides the IoT service has There is a problem that the terminal cannot be registered.

  An object of the present invention is to provide a relay node device, a communication control method, and a program that can reduce the amount of data held in a core network and register many terminals.

  A relay node device according to a first aspect of the present invention is a relay node device disposed in a core network for transmitting user data relating to a mobile station, wherein the subscriber data of the mobile station transmitted from the subscriber information management device is provided. A subscriber data holding unit for holding subscriber data of the mobile station in accordance with an IoT service policy when user data relating to the mobile station is not transmitted. And a control unit that determines

  A communication control method according to a second aspect of the present invention is a communication control method in a relay node device arranged in a core network for transmitting user data relating to a mobile station, wherein the mobile station transmitted from a subscriber information management device is provided. Holding the subscriber data of the mobile station, and determining whether to hold the subscriber data of the mobile station according to the IoT service policy when the user data regarding the mobile station is not transmitted. It is.

  A program according to a third aspect of the present invention is a program to be executed by a computer, which is located in a core network and is a relay node device for transmitting user data relating to a mobile station, the mobile station being transmitted from a subscriber information management device. Holding the subscriber data of the station, and determining whether to hold the subscriber data of the mobile station according to the IoT service policy when the user data regarding the mobile station is not transmitted. That is what makes a computer execute it.

  According to the present invention, it is possible to provide a relay node device, a communication control method, and a program that can reduce the amount of data held in a core network and register many terminals.

FIG. 2 is a configuration diagram of a communication system according to the first exemplary embodiment; FIG. 9 is a configuration diagram of a communication system according to a second exemplary embodiment; FIG. 14 is a diagram illustrating a flow of an Attach process according to the second embodiment; FIG. 13 is a diagram illustrating a flow of a process when no communication is detected according to the second exemplary embodiment; FIG. 9 is a configuration diagram of a communication system according to a third exemplary embodiment; FIG. 14 is a diagram illustrating a flow of an Attach process according to the third embodiment; FIG. 14 is a diagram showing a flow of a process when no communication is detected according to the third exemplary embodiment. FIG. 14 is a configuration diagram of a communication system according to a fourth embodiment. FIG. 14 is a diagram illustrating information managed by a DB according to the fourth embodiment. FIG. 14 is a diagram illustrating a flow of a packet distribution process according to the fourth embodiment. FIG. 19 is a diagram illustrating a flow of a packet distribution process according to the fifth embodiment. FIG. 14 is a configuration diagram of an SGSN according to a sixth embodiment. FIG. 21 is a diagram showing a flow of an Attach process according to the sixth embodiment. FIG. 21 is a diagram showing a flow when the UE according to the sixth embodiment starts packet communication. FIG. 21 is a diagram illustrating a processing flow when the UE according to the sixth embodiment completes the packet communication. FIG. 21 is a diagram showing a flow of a process when no communication is detected according to the sixth exemplary embodiment.

(Embodiment 1)
Hereinafter, embodiments of the present invention will be described with reference to the drawings. The communication system according to the first embodiment of the present invention will be described with reference to FIG. The communication system of FIG. 1 includes an eNB (evolved Node B) 10, a gateway device 20, an MME (Mobility Management Entity) 30, an MME 32, and a UE (User Equipment) 40. The UE 40, the eNB 10, the gateway device 20, and the MME 30 may be computer devices that operate by a processor executing a program stored in a memory.

  The eNB 10 is a base station that supports LTE (Long Term Evolution) in 3GPP. The eNB 10 performs wireless communication with the UE 40 using LTE as a wireless communication method. UE 40 is a generic term for mobile stations used in 3GPP.

  The MME 30 and the MME 32 are node devices that manage the location information of the UE 40 in 3GPP and further execute call processing control on the UE 40. The MME 30 and the MME 32 are node devices that configure a core network. Further, in FIG. 1, two MMEs 30 and 32 are shown, but three or more MMEs may be arranged.

  The gateway device 20 is arranged between the eNB 10 and the MME 30, and relays control data transmitted between the eNB 10 and the MME 30. The control data may be data for collecting location information of the UE 40, data for executing call processing control, and the like. The control data may be referred to as a control signal, control information, C-Plane data, or the like. Further, text data, image data, moving image data, and the like transmitted and received by the UE 40 are referred to as user data. The user data may be referred to as user information, U-Plane data, or the like.

  The eNB 10 and the MME 30 execute communication according to S1AP (S1 Application Protocol). That is, the eNB 10 and the MME 30 set various information in the S1AP message, which is a control message defined in the S1AP, and transmit the S1AP message. Between the eNB 10 and the MME 30 is defined as an S1 reference point in 3GPP. The eNB 10 and the MME 32 also execute communication according to the S1AP.

  Subsequently, a configuration example of the gateway device 20 will be described. The gateway device 20 has a communication unit 21, a determination unit 22, and a conversion unit 23. The communication unit 21, the determination unit 22, and the conversion unit 23 may be software or modules whose processing is executed by a processor executing a program stored in a memory. Alternatively, the communication unit 21, the determination unit 22, and the conversion unit 23 may be hardware such as a circuit or a chip.

  The communication unit 21 terminates the S1AP message transmitted from the eNB 10, the MME 30, or the MME 32. Terminating the S1AP message by the communication unit 21 may mean that the communication unit 21 analyzes the information set in the S1AP message, or changes the information set in the S1AP message. The communication unit 21 outputs the received S1AP message to the determination unit 22 and the conversion unit 23.

  The determination unit 22 determines the terminal type of the UE 40 associated with the S1AP message. The S1AP message is a message used to manage the location information of the UE 40 and to perform call processing control of the UE 40. That is, the S1AP message is transmitted for each UE.

  The terminal type may be, for example, identification information of a service executed by the UE 40, information defining traffic characteristics of the UE 40, or identification information for identifying another UE 40. For example, the terminal type may be information for identifying a terminal that executes an IoT service and another terminal.

  The conversion unit 23 changes the source address set in the S1AP message transmitted from the eNB 10 from the identifier of the eNB 10 to the identifier A of the gateway device 20. The identifier A is an identifier used for communication between the gateway device 20 and the MME 30 or between the gateway device 20 and the MME 32.

  Here, the communication unit 21 transmits the S1AP message with the source address converted to the MME 30 or MME 32 determined according to the terminal type. For example, the MME 30 and the MME 32 manage location information of the UE 40 of a specific terminal type, and further execute call processing control. In this case, the communication unit 21 transmits the S1AP message to the MME associated with the determined terminal type. In other words, the communication unit 21 distributes the S1AP message to a plurality of MMEs according to the terminal type.

  As described above, the gateway device 20 of FIG. 1 can terminate the S1AP message used for communication between the eNB 10 and the MME 30 in 3GPP. Further, the gateway device 20 can distribute the S1AP message to a plurality of MMEs according to the terminal type of the UE 40.

  Furthermore, the gateway device 20 can change the source address of the S1AP message transmitted from the eNB 10 from the eNB 10 to the gateway device 20. As a result, the gateway device 20 changes the identification information of the transmission source defined in the S1AP message, and transmits the S1AP message in which the identification information of the transmission source is changed to the MME, whereby the gateway device 20 changes the eNB 10, the MME 30, Even if the S1AP message is disposed between the MME 32 and the S1AP message, the S1AP message can be transmitted normally. That is, the MME sets the identification information of the gateway device 20 as the transmission destination of the S1AP message, so that the S1AP message transmitted between the eNB 10 and the MME can be transmitted via the gateway device 20. And

(Embodiment 2)
Subsequently, a configuration example of the communication system according to the second exemplary embodiment of the present invention will be described with reference to FIG. FIG. 2 shows that the MME 30 is located in the general network 50 and the MME 32 is located in the IoT network 52. Other configurations in FIG. 2 are the same as those in FIG. 1, and thus detailed description is omitted.

  The IoT network 52 is a network that transmits data on UEs used for IoT services. For example, the IoT network 52 may be a network that transmits control data and user data related to a UE used for an IoT service. The IoT network 52 may include an SGW (Serving Gateway) for transmitting user data and a PGW (Packet data network Gateway) in addition to the MME 32 for transmitting control data.

  The general network 50 is a network that transmits data regarding UEs other than the UE used for the IoT service. For example, a UE other than the UE used for the IoT service may be a mobile phone or a smartphone that requires a user operation when using the service.

  IoT services often transmit a small amount of data as compared to smartphones and the like. Further, the IoT service may have a traffic characteristic that data is transmitted at a predetermined timing during one day.

  On the other hand, a terminal such as a smartphone sometimes receives a large amount of moving image data. Furthermore, various services can be used using a smartphone terminal, and it is considered that the amount of data transmitted and received by the smartphone terminal has increased in recent years. As described above, the terminal used for the IoT service and the terminal used for other services have different traffic characteristics. Here, a network can be efficiently designed by handling traffic relating to terminals having the same traffic characteristics in the same network.

  For example, in the IoT network 52 that is a network that handles traffic related to terminals that transmit little user data, the number of node devices such as SGWs that relay user data may be reduced. In addition, the IoT network 52 may accommodate more terminals in the future as compared to smartphones and the like. Therefore, in the IoT network 52, the number of node devices such as MMEs that process control data may be increased.

  On the other hand, the general network 50 handles traffic related to terminals that transmit a lot of user data. Therefore, in the general network 50, the number of node devices such as SGWs that relay user data may be increased. In addition, the diffusion speed of smartphones and the like may slow down in the future. Therefore, in the IoT network 52, the number of node devices such as MMEs that process control data may be reduced, or the current number of node devices such as MMEs may be maintained.

  The gateway device 20 determines whether the UE 40 is a terminal used for the IoT service, and distributes a message related to the UE 40 to the MME 30 or the MME 32.

  Subsequently, a flow of the Attach process regarding the UE 40 will be described with reference to FIG. First, the UE 40 transmits an Attach Request message, which is a NAS (Non Access Stratum) message, to the eNB 10 (S11). The UE 40 may set information on the terminal type in the Attach Request message. The information on the terminal type may be, for example, information indicating whether or not the terminal is used for the IoT service. Specifically, the UE 40 may set information on the terminal type in Device-Properties, which is a parameter set in the NAS message.

  Next, the eNB 10 transmits an Initial UE Message, which is an S1AP message, to the gateway device 20 (S12). The eNB 10 multiplexes the Attach Request message received from the UE 40 into the Initial UE Message. That is, the eNB 10 transmits the Initial UE Message including the Attach Request message to the gateway device 20. The destination of the Initial UE Message may be set by the gateway device 20 or an arbitrary MME.

  The MME that transmits control data related to the UE 40 is determined in the gateway device 20. Therefore, when an arbitrary MME is set as the destination of the Initial UE Message, the destination of the Initial UE Message is changed in the gateway device 20. Further, even when an arbitrary MME is set as the destination of the Initial UE Message, the communication path is set so that the Initial UE Message is transmitted to the gateway device 20.

  Next, the gateway device 20 determines a distribution destination of the Initial UE Message that is the S1AP message (S13). In other words, the gateway device 20 determines the transmission destination of the Initial UE Message. The gateway device 20 determines the distribution destination of the Initial UE Message using the information on the terminal type set in the Attach Request message included in the Initial UE Message. When information indicating that the terminal is a terminal used for the IoT service is set in the terminal type, the gateway device 20 determines that the initial UE message is to be distributed to the MME 32. FIG. 3 illustrates a case where the gateway device 20 determines that the distribution destination of the Initial UE Message is the MME 32.

  Next, the gateway device 20 changes or replaces the source address of the Initial UE Message from the identifier of the eNB 10 to the identifier of the gateway device 20 (S14). The source address of the Initial UE Message is an address in the S1AP layer defined in the S1AP. The identifier set to the source address of the Initial UE Message is eNB-S1AP-id. For example, upon receiving an Initial UE Message with eNB-S1AP-id = A set as the source address, the gateway device 20 changes the source address to eNB-S1AP-id = C. The gateway device 20 manages eNB-S1AP-id = A and eNB-S1AP-id = C in association with each other. In other words, the gateway device 20 assigns eNB-S1AP-id = C to eNB-S1AP-id = A.

  Next, the gateway device 20 transmits the Initial UE Message whose source address has been changed to the MME 32 (S15). Next, the MME 32 transmits a Downlink NAS Transport message, which is an S1AP message, to the gateway device 20 (S16). The MME 32 sets eNB-S1AP-id = C as the destination of the Downlink NAS Transport message. For example, the MME 32 multiplexes an Authentication Request message used for performing authentication on the UE 40 into a Downlink NAS Transport message. The Authentication Request message is a NAS message.

  Next, the gateway device 20 changes or replaces the source address of the Downlink NAS Transport message from the identifier of the MME 32 to the identifier of the gateway device 20 (S17). The source address of the Downlink NAS Transport message is an address in the S1AP layer defined in the S1AP. The identifier set for the source address of the Downlink NAS Transport message is MME-S1AP-id. For example, upon receiving a Downlink NAS Transport message with MME-S1AP-id = D set as the source address, the gateway device 20 changes the source address to MME-S1AP-id = B. The gateway device 20 manages MME-S1AP-id = D and MME-S1AP-id = B in association with each other. In other words, the gateway device 20 allocates MME-S1AP-id = B to MME-S1AP-id = D.

  Next, the gateway device 20 transmits a Downlink NAS Transport message in which the source address has been changed to the eNB 10 (S18). Further, the gateway device 20 changes eNB-S1AP-id = C set as the destination in the Downlink NAS Transport message to eNB-S1AP-id = A associated with eNB-S1AP-id = C. Here, when receiving the Downlink NAS Transport message, the eNB 10 transmits an Authentication Request message included in the Downlink NAS Transport message to the UE 40.

  Next, the UE 40 transmits an Authentication Response that is a NAS message, and the eNB 10 multiplexes the Authentication Response message into an Uplink NAS Transport message that is an S1AP message. The eNB 10 transmits an Uplink NAS Transport message in which an Authentication Response message is multiplexed to the gateway device 20 (S19). Here, the eNB 10 sets MME-S1AP-id = B as the destination of the Uplink NAS Transport message.

  Next, the gateway device 20 changes the source address of the Uplink NAS Transport message from eNB-S1AP-id = A to eNB-S1AP-id = C, and further changes the destination address to MME-S1AP-id = C. Change from B to MME-S1AP-id = D (S20). Thereafter, in order to execute the Attach process of the UE 40, the Downlink NAS Transport message and the Uplink NAS Transport message are transmitted as in steps S16 to S21.

  Next, when the Attach process for the UE 40 is completed, the MME 32 multiplexes an Attach Accept message, which is a NAS message, with an Initial Context Setup Request message, which is an S1AP message, and transmits the multiplexed message to the gateway device 20 (S22). Here, as in step S17, the gateway device 20 performs address conversion and transmits an Initial Context Setup Request message to the eNB 10.

  Next, the eNB 10 executes an E-RAB Setup process to set a radio bearer with the UE 40 (S23). Next, the eNB 10 transmits a UE Radio Access Capability Information message, which is an S1AP message, to the gateway device 20 to notify the MME 32 of the capability information of the UE 40 or the performance information (S24). Here, as in step S20, the gateway device 20 performs address conversion and transmits a UE Radio Access Capability Information message to the MME32.

  Next, the UE 40 transmits an Attach Complete message that is a NAS message, and the eNB 10 multiplexes the Attach Complete message into an Uplink NAS Transport message that is an S1AP message. The eNB 10 transmits an Uplink NAS Transport message multiplexing the Attach Complete message to the gateway device 20 (S25). Here, as in step S20, the gateway device 20 performs the address conversion and transmits an Uplink NAS Transport message to the MME32.

  Thereafter, an Uplink / Downlink Packet, which is user data regarding the UE 40, is transmitted between the eNB 10 and the SGW. The SGW is a node device arranged in the IoT network 52. Uplink / Downlink Packet transmitted between the eNB 10 and the SGW is transmitted via the gateway device 20 in the same manner as control data. In this case, the gateway device 20 performs the conversion of the address set in the Uplink / Downlink Packet as in steps S17 and S20.

  Next, a flow of processing when no communication is detected according to the second embodiment of the present invention will be described with reference to FIG. First, the eNB 10 detects that the UE 40 has not performed communication for a predetermined period and is in a non-communication state (S31).

  Next, the eNB 10 transmits a UE Context Release Request message, which is an S1AP message, to the MME 32 via the gateway device 20 in order to release a radio bearer with the UE 40 (S32). The gateway device 20 performs the address conversion as in step S20 of FIG.

  Next, the MME 32 transmits a UE Context Release Command message, which is an S1AP message, to the eNB 10 via the gateway device 20 to instruct to release the radio bearer between the UE 40 and the eNB 10 (S33). The gateway device 20 performs the address conversion as in step S17 of FIG.

  Next, the eNB 10 executes a process of releasing the radio bearer with the UE 40 (S34). Next, the eNB 10 transmits a UE Context Release Complete message, which is an S1AP message, to the MME 32 via the gateway device 20 (S35). The gateway device 20 performs the address conversion as in step S20 of FIG.

  Next, the gateway device 20 associates eNB-S1AP-id = A with eNB-S1AP-id = C, and further associates MME-S1AP-id = B with MME-S1AP-id = D. The management information is released or deleted (S36). In other words, the gateway device 20 assigns eNB-S1AP-id = C assigned to eNB-S1AP-id = A and MME-S1AP-id = B assigned to MME-S1AP-id = D. release.

  As described above, by executing the Attach process according to the second embodiment of the present invention, the gateway device 20 can select the MME according to the terminal type of the UE 40 and distribute the S1AP message to the selected MME. it can. Also, the gateway device 20 can terminate and transfer the S1AP message between the eNB 10 and the MME via the gateway device 20 by converting the address information set in the S1AP message. That is, the gateway device 20 can relay the S1AP message transmitted between the eNB 10 and the MME by converting the address of the S1AP message transmitted between the eNB 10 and the MME.

(Embodiment 3)
Subsequently, a configuration example of the communication system according to the third exemplary embodiment of the present invention will be described with reference to FIG. The communication system of FIG. 5 replaces the eNB 10 of the communication system of FIG. 2 with an RNC (Radio Network Controller) 12, and replaces the MME 30 and MME 32 of the communication system of FIG. ing. Further, the SGSN 31 is arranged in the general network 50, and the SGSN 33 is arranged in the IoT network 52. The gateway device 20 of FIG. 5 has the same configuration as the gateway device 20 of FIGS.

  The RNC 12 is a node device that controls a radio access network called 3G. The SGSN 31 and the SGSN 33 are node devices that manage the location information of the UE 40 and further perform call processing control on the UE 40. The SGSN 31 and the SGSN 33 transmit control data and user data related to the UE 40.

  Next, a flow of the Attach process of the UE 40 according to the third embodiment of the present invention will be described using FIG. First, the UE 40 transmits an Attach Request message, which is a NAS message, to the RNC 12 (S41). The UE 40 may set information on the terminal type in the Attach Request message. The information on the terminal type may be, for example, information indicating whether or not the terminal is used for the IoT service. The UE 40 may set information on the terminal type in Device-Properties, which is a parameter set in the NAS message.

  Next, the RNC 12 transmits an Initial UE Message, which is a RANAP (Radio Access Network Application Part) protocol message, to the gateway device 20 (S42). The RNC 12 multiplexes the Attach Request message received from the UE 40 into an Initial UE Message. That is, the RNC 12 transmits an Initial UE Message including the Attach Request message to the gateway device 20. The destination of the Initial UE Message may be set by the gateway device 20 or an arbitrary SGSN.

  The SGSN for transmitting control data related to the UE 40 is determined in the gateway device 20. Therefore, when an arbitrary SGSN is set in the Initial UE Message, the gateway device 20 changes the destination of the Initial UE Message.

  Next, the gateway device 20 determines a distribution destination of the Initial UE Message which is a RANAP protocol message (S43). In other words, the gateway device 20 determines the transmission destination of the Initial UE Message. The gateway device 20 determines the distribution destination of the Initial UE Message using the information on the terminal type set in the Attach Request message included in the Initial UE Message. When information indicating that the terminal is a terminal used for the IoT service is set in the terminal type, the gateway device 20 determines that the initial UE message is allocated to the SGSN 33. FIG. 6 illustrates a case where the gateway device 20 determines that the distribution destination of the Initial UE Message is the SGSN 33.

  Next, the gateway device 20 changes or replaces the source address of the Initial UE Message from the identifier of the RNC 12 to the identifier of the gateway device 20 (S44). The source address of the Initial UE Message is an address in the SCCP layer defined in the RANAP protocol. The identifier set to the source address of the Initial UE Message is Source-LR. For example, upon receiving an Initial UE Message with Source-LR = A1 set as the source address, the gateway device 20 changes the source address to Source-LR = C1. The gateway device 20 manages Source-LR = A1 and Source-LR = C1 in association with each other. In other words, the gateway device 20 assigns Source-LR = C1 to Source-LR = A1.

  Next, the gateway device 20 transmits the Initial UE Message whose source address has been changed to the SGSN 33 (S45). Next, the SGSN 33 transmits a Direct Transfer message, which is a RANAP protocol message, to the gateway device 20 (S46). The SGSN 33 sets Source-LR = C1 as the destination of the Direct Transfer message.

  Next, the gateway device 20 changes or changes the address of the source of the Direct Transfer message from the identifier of the SGSN 33 to the identifier of the gateway device 20 (S47). The source address of the Direct Transfer message is an address in the SCCP layer defined in the RANAP protocol. The identifier set to the source address of the Direct Transfer message is Source-LR = D1. For example, upon receiving a Direct Transfer message with Source-LR = D1 set as the source address, the gateway device 20 changes the source address to Source-LR = B1. The gateway device 20 manages Source-LR = D1 and Source-LR = B1 in association with each other. In other words, the gateway device 20 assigns Source-LR = B1 to Source-LR = D1.

  Next, the gateway device 20 transmits a Direct Transfer message in which the source address has been changed to the RNC 12 (S48). Further, the gateway device 20 changes Source-LR = C1 set as the destination in the Direct Transfer message to Source-LR = A1 associated with Source-LR = C1. Here, when receiving the Direct Transfer message, the RNC 12 transmits the NAS message included in the Direct Transfer message to the UE 40.

  The subsequent Attach processing is a known processing defined in the 3GPP, and a detailed description thereof will be omitted. Although the flow of the Attach process has been described with reference to FIG. 6, the gateway device 20 can also terminate and transfer the RANAP protocol message between the RNC 12 and the SGSN 31 in the PDP connection process.

  Next, the flow of the radio bearer release processing according to the third embodiment of the present invention will be described using FIG. First, the SGSN 33 transmits an Iu Release Command message, which is a RANAP protocol message, to the RNC 12 via the gateway device 20 to instruct to release a radio bearer between the UE 40 and the RNC 12 (S51). The gateway device 20 performs the address conversion as in step S47 of FIG.

  Next, the RNC 12 executes a process of releasing the radio bearer with the UE 40 (S52). Next, the RNC 12 transmits an Iu Release Complete message, which is a RANAP protocol message, to the SGSN 33 via the gateway device 20 (S53). The gateway device 20 performs the address conversion as in step S44 of FIG.

  Next, the gateway device 20 releases or deletes management information in which Source-LR = A1 and Source-LR = C1 are associated, and further, management information in which Source-LR = B1 is associated with Source-LR = D1. (S54). In other words, the gateway device 20 releases Source-LR = C1 assigned to Source-LR = A1 and Source-LR = B1 assigned to Source-LR = D1.

  As described above, the communication system according to the third embodiment of the present invention can terminate and transfer a RANAP protocol message between the RNC 12 and the SGSN 31 as in the second embodiment.

(Embodiment 4)
Next, a configuration example of the communication system according to the fourth exemplary embodiment of the present invention will be described with reference to FIG. In the communication system of FIG. 8, a DB (database) 60 and an HSS (Home Subscriber Server) 64 are added to the communication system of FIG. Further, an IoT core network 71, an IoT core network 72, and an IoT core network 73 exist in the IoT network 52, and the MME 36 is arranged in the IoT core network 71, and the MME 37 is located in the IoT core network 72. The MME 38 is arranged in the IoT core network 73. Further, a server device 81 is connected to the IoT core network 71, a server device 82 is connected to the IoT core network 72, and a server device 83 is connected to the IoT core network 73.

  The IoT network 52 is divided into IoT core networks such as an IoT core network 71, an IoT core network 72, and an IoT core network 73 for each IoT service to be provided. Alternatively, a plurality of IoT services may be provided in one IoT core network.

  IoT services include, for example, a service for managing smart meters, a service for controlling traffic, a service related to government offices or emergency agencies, a service for managing logistics, a service for providing security, and a service for managing inventory. There are various services.

  Further, the server device 81, the server device 82, and the server device 83 may be server devices managed by a service provider that provides an IoT service. That is, the IoT core network 71 may be referred to as an IoT core network provided to a service provider that manages the server device 81. The IoT core network 72 and the IoT core network 73 are the same as the IoT core network 71.

  The gateway device 20 terminates the S1AP message transmitted from the eNB 10, and specifies a core network transmitting the S1AP message from among a plurality of IoT core networks. The gateway device 20 uses the DB 60 when specifying the core network transmitting the S1AP message.

  The DB 60 manages the identification information of the UE 40 in association with the identification information of the IoT core network in which the UE 40 is registered. The gateway device 20 extracts the identification information of the IoT core network associated with the UE 40 from the DB 60 using the identification information of the UE 40 included in the S1AP message. Further, the gateway device 20 transmits an S1AP message to the MME located in the specified IoT core network.

  HSS 64 manages subscriber information for multiple UEs. For example, the HSS 64 manages a telephone number and location information of each UE. The MMEs 35 to 38 execute call processing control and the like using the subscriber information managed in the HSS 64.

  Next, information managed by the DB 60 will be described with reference to FIG. The DB 60 has an information management unit 61 and an information management unit 62. The information management unit 61 and the information management unit 62 may be a memory or the like in the DB 60, or may be an external memory or the like attached to the DB 60.

  The information management unit 61 manages information on the IoT type in association with information on the CN (core network) type. The information on the IoT type may be, for example, information for identifying an IoT service. In FIG. 9, numbers 1 to 4 are used as information on the IoT type. The information on the CN type is information for identifying the IoT core network. In FIG. 9, reference numerals 71 to 73 assigned to each IoT core network in FIG. 8 are used as the information on the CN type.

  The information management unit 62 manages information on the subscriber number and information on the IoT type in association with each other. The information on the subscriber number may be, for example, a telephone number or a machine number assigned to the UE 40. In FIG. 9, letters A to D are used as information on the subscriber number.

  Next, the flow of the packet distribution processing according to the fourth embodiment of the present invention will be described with reference to FIG. First, the DB 60 registers the information shown in FIG. 9 (S61). For example, the DB 60 may acquire the information illustrated in FIG. 9 from another server device or the like, or may input the information illustrated in FIG. 9 from a user or the like who manages the DB 60.

  Next, the UE 40 transmits a packet communication start request message to the eNB 10 to start packet communication (S62). The UE 40 sets the subscriber number in the packet communication start request message. Here, it is assumed that the UE 40 has set the subscriber number A in the packet communication start request message. Next, the eNB 10 transmits the packet communication start request message received from the UE 40 to the gateway device 20 (S63). At this time, the eNB 10 transmits a packet communication start request message to the gateway device 20 as an S1AP message used for communication between the eNB 10 and the MME.

  Next, the gateway device 20 terminates the packet communication start request message, which is the S1AP message transmitted from the eNB 10, and extracts the subscriber number of the UE 40. Further, the UE 40 transmits a Query message in which the extracted subscriber number A is set to the DB 60 (S64). When receiving the Query message in which the subscriber number is set, the DB 60 specifies the IoT type associated with the subscriber number using the information management unit 62. Further, the DB 60 uses the information management unit 61 to specify the CN type associated with the IoT type. Here, since the subscriber number A is set in the Query message, the DB 60 specifies the IoT type: 2 and the CN type: 72.

  Next, the DB 60 transmits an Answer message in which the CN type: 72 is set to the gateway device 20 (S65). Next, the gateway device 20 determines a distribution destination of the packet communication start request message (S66). In other words, the gateway device 20 determines the transmission destination of the packet communication start request message. The gateway device 20 determines to transmit a packet communication start request message to the MME 37 located in the IoT core network 72 corresponding to the CN type: 72 set in the Answer message.

  Next, the gateway device 20 changes the source address of the packet communication start request message, which is the S1AP message to be transmitted to the MME 37, from the identification information of the eNB 10 to the identification information of the gateway device 20 (S67). The address conversion processing in step S67 is the same as the address conversion processing in steps S14 and S20 in FIG. 3, and thus detailed description is omitted.

  Next, the gateway device 20 transmits a packet communication start request message to the MME 37 (S68). Next, the MME 37 transmits a location registration request message to the HSS 64 to request transmission of the location registration information of the UE 40 (S69). Next, the HSS 64 transmits the subscriber information including the location information of the UE 40 to the MME 37 (S70).

  As described above, by using the communication system according to the fourth embodiment of the present invention, when there is an IoT core network separated for each IoT service, the gateway device 20 transmits data related to the IoT service used by the UE 40. Can be relayed to the IoT core network that transmits the data.

  Here, when registering the information on the subscriber number, the IoT type, and the CN type in step S61, the information may be registered in the DB 60 based on the registration status of the subscriber in each MME.

  For example, a case will be described in which there are a plurality of IoT core networks that transmit data related to the same IoT service. In this case, an external monitoring device or the like may monitor the number of UEs registered in each IoT core network. Furthermore, the external monitoring device and the like are configured so that the number of UEs registered in each IoT core network is equal or the number of UEs registered in some IoT core networks is not biased. The IoT type associated with the UE may be determined. The external monitoring device or the like may transmit the determined information in which the subscriber number is associated with the IoT type to the DB 60.

  That is, the information in which the subscriber number is associated with the IoT type may be transmitted from the external monitoring device or the like to the DB 60 periodically or at an arbitrary timing according to the registration status of the UE.

  Further, in the fourth embodiment, RNC may be used instead of eNB 10, and SGSN may be used instead of MME.

  Also, in the first to third embodiments, as described in the fourth embodiment, the gateway device 20 may use the DB 60 to determine a message distribution destination.

(Embodiment 5)
Next, the flow of the packet distribution processing according to the fifth embodiment of the present invention will be described with reference to FIG. First, the DB 60 registers information managed by the information management unit 61 shown in FIG. 9 (S81). Further, the HSS 64 registers information managed by the information management unit 62 shown in FIG. 9 (S82).

  Steps S83 to S85 are the same as steps S62 to S64 in FIG. 10 and thus will not be described in detail. When receiving the Query message in which the subscriber number A of the UE 40 is set, the DB 60 transmits the received Query message to the HSS 64 (S86).

  Next, upon receiving the Query message in which the subscriber number A is set, the HSS 64 specifies the IoT type: 2 associated with the subscriber number A. The HSS 64 transmits an Answer message in which the IoT type: 2 is set to the DB 60 (S87).

  Next, the DB 60 transmits an Answer message in which the CN type: 72 associated with the IoT type: 2 is set to the gateway device 20 (S88). Steps S89 to S93 are the same as steps S66 to S70 in FIG. 10, and thus detailed description is omitted.

  As described above, the information managed in the DB 60 and the HSS 64 is used when performing the packet distribution processing according to the fifth embodiment of the present invention. Information used for the packet distribution processing is distributed and managed in the DB 60 and the HSS 64. Thus, the memory capacity of the DB 60 according to the fifth embodiment can be reduced as compared with the DB 60 according to the fourth embodiment.

  The UE 40 used for the IoT service may be a terminal dedicated to the IoT service, such as a smart meter or an in-vehicle terminal. Therefore, the IoT type may be registered in the UE 40 used for the IoT service in advance. For example, the IoT type may be registered in the UE 40 when the UE 40 is manufactured, shipped, or contracted with a communication carrier.

  In this case, the UE 40 may set information on the IoT type together with the subscriber number in the packet communication start request message in step S83. Thus, when the DB 60 receives the Query message in which the IoT type is set, the DB 60 can transmit the Answer message in which the CN type associated with the IoT type is set to the gateway device 20 without transmitting the Query message to the HSS 64. it can.

  Further, in the fifth embodiment, RNC may be used instead of eNB 10, and SGSN may be used instead of MME.

(Embodiment 6)
Next, a configuration example of the SGSN 31 according to the sixth embodiment of the present invention will be described with reference to FIG. The other SGSNs other than the SGSN 31 have the same configuration as the SGSN 31, and a detailed description thereof will be omitted. Further, the SGSN 31 may be referred to as a relay node device or the like arranged in the core network.

  The SGSN 31 includes a control unit 91, a subscriber data holding unit 92, and a session information holding unit 93. The control unit 91 may be software or a module that operates when the processor executes a program stored in the memory. Alternatively, the control unit 91 may be hardware such as a circuit or a chip. The subscriber data holding unit 92 and the session information holding unit 93 may be memories in the SGSN 31 or external memories attached to the SGSN 31.

  The subscriber data holding unit 92 holds the subscriber data of the UE 40 transmitted from the HSS 64 as the subscriber information management device. When the subscriber data holding unit 92 holds the subscriber data of the UE 40, the process of the SGSN 31 acquiring the subscriber data from the HSS 64 when the UE 40 performs communication can be omitted. The subscriber data may be referred to as, for example, VLR (Visitor Location Register) information.

  The subscriber data holding unit 92 holds, for example, the subscriber data regarding the UE 40 transmitted from the HSS 64 during the Attach processing regarding the UE 40.

  The session information holding unit 93 holds session information on the UE 40. The session information is information used in a protocol higher than the network layer, and may be identification information for uniquely identifying the UE 40 in the radio network between the UE 40 and the RNC 12, and in the core network. The session information may be referred to as, for example, PDP (Packet Data Protocol) information or a PDP context. The session information holding unit 93 holds session information on the UE 40 while user data on the UE 40 is transmitted.

  The control unit 91 determines whether or not the subscriber data holding unit 92 holds the subscriber data of the UE 40. Further, control section 91 determines whether or not session information holding section 93 holds session data of UE 40.

  The control unit 91 determines whether or not the subscriber data holding unit 92 holds the subscriber data of the UE 40 in accordance with the IoT service policy when the transmission of the user data regarding the UE 40 is not performed.

  The case where the transmission of the user data regarding the UE 40 is not performed is, for example, a case where the non-communication state of the UE 40 is detected during the Attach process executed before the transmission of the user data regarding the UE 40 is performed. You may.

  In the IoT service policy, for example, a connection time from when the UE 40 requests the start of packet communication to when the UE 40 connects to the core network may be determined. Specifically, the connection time may be a time from when the UE 40 requests the start of the packet communication to when the packet communication is actually executed.

  For example, a case where the UE 40 starts packet communication when the subscriber data holding unit 92 does not hold the subscriber data of the UE 40 will be described. In this case, the SGSN 31 needs to acquire the subscriber data from the HSS 64 in order to execute the packet communication of the UE 40. That is, compared to the case where the subscriber data holding unit 92 holds the subscriber data about the UE 40, the UE 40 performs the packet communication for the time during which the SGSN 31 performs the process of acquiring the subscriber data about the UE 40 from the HSS 64. Takes extra time to execute.

  On the other hand, when the subscriber data holding unit 92 does not hold the subscriber data regarding the UE 40, the memory capacity can be reduced. Therefore, even when the subscriber data holding unit 92 does not hold the subscriber data relating to the UE 40, the control unit 91 does not exceed the connection time defined in the IoT service policy. May determine that the subscriber data regarding the UE 40 is not held.

  In addition, the IoT service policy may determine whether to permit SMS termination for the UE 40. For example, when the subscriber data holding unit 92 does not hold the subscriber data relating to the UE 40, the SMS termination for the UE 40 may not be executed normally. Therefore, when the IoT service policy stipulates that the incoming SMS to the UE 40 is permitted, the control unit 91 may determine that the subscriber data holding unit 92 holds the subscriber data regarding the UE 40. On the other hand, when the IoT service policy stipulates that the incoming SMS to the UE 40 is not permitted, the control unit 91 may determine that the subscriber data holding unit 92 does not hold the subscriber data regarding the UE 40.

  IoT service policies differ for each service provider. That is, the IoT service policy differs for each IoT core network. Therefore, the SGSN arranged in each IoT core network holds information on IoT service policies in advance.

  Next, a flow of the Attach process according to the sixth embodiment of the present invention will be described with reference to FIG. First, the UE 40 transmits an Attach Request message to the SGSN 31 via the RNC 12 (S101). The UE 40 sets, for example, an International Mobile Subscriber Identity (IMSI), which is identification information of the UE 40, in the Attach Request message.

  Next, the SGSN 31 transmits a MAP-Send Authentication Info message in which the IMSI of the UE 40 is set to the HSS 64 (S102). Next, the HSS 64 transmits a MAP-Send Authentication Info Ack message to the SGSN 31 as a response message to the MAP-Send Authentication Info message (S103). The HSS 64 sets authentication information on the UE 40 in the MAP-Send Authentication Info Ack message.

  Next, the SGSN 31 performs an authentication process on the UE 40 using the authentication information on the UE 40 transmitted from the HSS 64 (S104). Next, the SGSN 31 transmits a MAP-Update GPRS Location message to the HSS 64 (S105). The SGSN 31 sets the IMSI of the UE 40 and the SGSN number of the own device in a MAP-Update GPRS Location message (S105). Next, the HSS 64 transmits a MAP-Insert Subscriber Data message to the SGSN 31 (S106). The HSS 64 sets the subscriber data on the UE 40 in a MAP-Insert Subscriber Data message.

  Next, the SGSN 31 transmits an Attach Accept message to the UE 40 via the RNC 12 (S107). Next, the UE 40 transmits an Attach Complete message to the SGSN 31 via the RNC 12 (S108).

  Upon receiving the Attach Complete message, the SGSN 31 determines whether to retain the subscriber data of the UE 40 based on the IoT service policy, and here determines that the subscriber data (VLR information) is not generated (S109). .

  Subsequently, a case where the UE 40 starts packet communication in a state where the SGSN 31 has not generated subscriber data will be described with reference to FIG. First, the UE 40 transmits a Service Request message to the SGSN 31 via the RNC 12 to start packet communication (S111). When receiving the Service Request message from the UE 40, the SGSN 31 transmits a Service Reject message to the UE 40 because the SGSN 31 does not hold the subscriber data of the UE 40 (S112). The SGSN 31 rejects the packet communication of the UE 40 by transmitting a Service Reject message to the UE 40 via the RNC 12.

  After step S113, the UE 40 performs a process for starting packet communication. Steps S113 to S116 are the same as steps S101 to S104 in FIG. 13 and thus will not be described in detail.

  When the authentication process for the UE 40 is completed in step S116, the UE 40 transmits an Active PDP Context Request message to the SGSN 31 via the RNC 12 (S117). Steps S118 and S119 are the same as steps S105 and S106 in FIG. 13 and thus will not be described in detail.

  Next, in step S119, the SGSN 31 holds the subscriber data transmitted from the HSS 64, in other words, generates VLR information (S120). For example, the SGSN 31 may determine that the subscriber data transmitted from the HSS 64 is retained in the Attach process after transmitting the Service Reject message.

  Next, in the UE 40, the RNC 12, and the SGSN 31, a process for establishing a RAB (Radio Access Bearer) is performed between the UE 40 and the RNC 12 (S121).

  Next, the SGSN 31 transmits an Active PDP Context Accept message to the UE 40 via the RNC 12 (S122). The Active PDP Context Accept message is a response message to the Active PDP Context Request message in step S117.

  Next, the UE 40, the RNC 12, and the SGSN 31 hold PDP information on the UE 40 (S123). The UE 40, the RNC 12, and the SGSN 31 hold PDP information on the UE 40, so that the UE 40 can execute packet communication.

  Subsequently, a flow of processing when packet communication in the UE 40 is completed will be described with reference to FIG. The UE 40 and the RNC 12 are in a state of holding PDP information, and the SGSN 31 is in a state of holding PDP information and VLR information (S131).

  When terminating the packet communication, the UE 40 transmits a Deactivate PDP Context Request message to the SGSN 31 via the RNC 12 (S132). Next, the SGSN 31 transmits a Deactivate PDP Context Accept message to the UE 40 via the RNC 12 (S133).

  Upon transmitting or receiving the Deactivate PDP Context Accept message, the UE 40, the RNC 12, and the SGSN 31 delete the PDP information (S134). Next, the SGSN 31 determines whether to delete the VLR information based on the IoT service policy or the information on whether or not to allow the SMS reception. (S135).

  Subsequently, the flow of processing when the UE 40 detects that the UE 40 is in a non-communication state will be described with reference to FIG. The UE 40 and the RNC 12 are in a state of holding PDP information, and the SGSN 31 is in a state of holding PDP information and VLR information (S141).

  When determining that the RNC 12 has not transmitted user data with the UE 40 for a predetermined period, the RNC 12 transmits a no-communication detection message to the SGSN 31 (S142). Next, the RNC 12 that has transmitted the no-communication detection message and the SGSN 31 that has received the no-communication detection message delete the PDP information (S143). The UE 40 is in a state of holding the PDP information.

  Next, the SGSN 31 determines whether to delete the VLR information based on the IoT service policy or the information on whether or not to permit the SMS reception (S144).

  As described above, it is possible to determine whether to hold the PDP information and the VLR information by using the SGSN according to the sixth embodiment of the present invention. When the SGSN deletes the PDP information or the VLR information based on the service policy, the SGSN can save the memory capacity.

  Since it is expected that the number of terminals used for the IoT service will increase in the future, the number of terminals accommodated in the SGSN can be increased by saving the memory capacity allocated to the PDP information and the VLR information in the SGSN.

  In FIGS. 13, 15, and 16, it is described that the VLR information is deleted when the SMS reception is not permitted. However, when the SMS reception for the UE 40 is notified in a state where the VLR information is deleted, the SGSN 31 may execute the SMS reception process by acquiring the VLR information regarding the UE 40 from the HSS 64.

  Further, in Embodiment 6, an eNB may be used instead of RNC 12, and an MME may be used instead of SGSN 31.

  In the above embodiment, the present invention has been described as a hardware configuration, but the present invention is not limited to this. The present invention can also realize the processing in the gateway device or other node devices by causing a CPU (Central Processing Unit) to execute a computer program.

  In the above example, the program may be stored using various types of non-transitory computer readable media and provided to a computer. Non-transitory computer readable media include various types of tangible storage media. Examples of non-transitory computer readable media are magnetic recording media (eg, flexible disk, magnetic tape, hard disk drive), magneto-optical recording media (eg, magneto-optical disk), CD-ROM (Read Only Memory), CD-R, CD-R / W, semiconductor memory (for example, mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM (Random Access Memory)). Also, the program may be supplied to the computer by various types of transitory computer readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line such as an electric wire and an optical fiber, or a wireless communication line.

  It should be noted that the present invention is not limited to the above-described embodiment, and can be appropriately changed without departing from the gist.

10 eNB
12 RNC
Reference Signs List 20 gateway device 21 communication unit 22 determination unit 23 conversion unit 30 MME
31 SGSN
32 MME
33 SGSN
35 MME
36 MME
37 MME
38 MME
40 UE
50 General Network 52 IoT Network 60 DB
61 Information management unit 62 Information management unit 64 HSS
71 IoT core network 72 IoT core network 73 IoT core network 81 server device 82 server device 83 server device 91 control unit 92 subscriber data holding unit 93 session information holding unit

Claims (10)

A relay node device arranged in a core network for transmitting user data related to a mobile station,
A subscriber data holding unit for holding subscriber data of the mobile station transmitted from the subscriber information management device;
A control unit that determines whether to retain the subscriber data of the mobile station in the subscriber data retaining unit according to an IoT service policy when transmission of user data relating to the mobile station is not performed ,
The control unit includes:
When the IoT service policy allows the connection delay time when the mobile station connects to the core network to execute communication to be longer than a predetermined time, the subscriber data holding unit A relay node device that determines to delete subscriber data of the mobile station .   A relay node device arranged in a core network for transmitting user data related to a mobile station,
  A subscriber data holding unit for holding subscriber data of the mobile station transmitted from the subscriber information management device;
  A control unit that determines whether to retain the subscriber data of the mobile station in the subscriber data retaining unit according to an IoT service policy when transmission of user data relating to the mobile station is not performed,
  The control unit includes:
  A relay node device that determines that the subscriber data holding unit deletes the subscriber data of the mobile station when SMS reception for the mobile station is not permitted as the IoT service policy. The control unit includes:
When the mobile station detects that the mobile station has not transmitted user data after the mobile station has established a session used for transmitting the user data, determines whether to hold the subscriber data of the mobile station in the data holding unit, the relay node device according to claim 1 or 2. The control unit includes:
After determining that the subscriber data holding unit does not hold the subscriber data of the mobile station at the time of the Attach processing, when receiving a message requesting the start of packet communication from the mobile station, the subscriber data holding unit 4. The relay node device according to claim 3 , wherein the relay node device determines to retain the subscriber data of the mobile station. Further comprising a session information holding unit that holds session information about the mobile station,
The control unit includes:
The method according to claim 1, wherein, when user data regarding the mobile station is not transmitted, it is determined whether to hold session information of the mobile station held in the session information holding unit according to an IoT service policy. 5. The relay node device according to any one of 4 . The control unit includes:
In a state where the subscriber data holding unit does not hold the subscriber data of the mobile station, when the SMS termination is notified to the mobile station, the subscriber information management device sends the subscriber data of the mobile station. The relay node device according to any one of claims 1 to 5 , wherein the relay node device obtains the following. A communication control method in a relay node device that is arranged in a core network and transmits user data related to a mobile station,
The subscriber data of the mobile station transmitted from the subscriber information management device and hold,
Wherein when the transmission of the user data for the mobile station is not performed, it is determined whether or not to retain the subscriber data of the mobile station in accordance with IoT service policy,
In the determination as to whether or not to retain the subscriber data of the mobile station, the connection delay time when the mobile station connects to the core network in order to execute communication is set to be longer than a predetermined time as the IoT service policy. A communication control method for determining that the subscriber data of the mobile station is to be deleted when the length of the mobile station is also allowed to be longer . A communication control method in a relay node device that is arranged in a core network and transmits user data related to a mobile station,
  Holding the subscriber data of the mobile station transmitted from the subscriber information management device,
  Determining whether to retain subscriber data of the mobile station according to an IoT service policy when user data transmission for the mobile station is not performed;
  In the determination as to whether or not to retain the subscriber data of the mobile station, when the IoT service policy does not permit incoming SMS to the mobile station, it is determined that the subscriber data of the mobile station is to be deleted. Control method. A program that is arranged in a core network and executed by a computer that is a relay node device that transmits user data related to a mobile station,
The subscriber data of the mobile station transmitted from the subscriber information management device and hold,
Determining whether to retain subscriber data of the mobile station according to an IoT service policy when transmission of user data relating to the mobile station is not performed ;
In the determination as to whether or not to retain the subscriber data of the mobile station, the connection delay time when the mobile station connects to the core network in order to execute communication is set to be longer than a predetermined time as the IoT service policy. A program that causes a computer to determine that the subscriber data of the mobile station is to be deleted if the length of the mobile station is also allowed to be longer .   A program which is arranged in a core network and executed by a computer which is a relay node device for transmitting user data relating to a mobile station,
  Holding the subscriber data of the mobile station transmitted from the subscriber information management device,
  Determining whether to retain subscriber data of the mobile station according to an IoT service policy when user data transmission for the mobile station is not performed;
  In the determination as to whether or not to retain the subscriber data of the mobile station, it is determined that the subscriber data of the mobile station is to be deleted if SMS reception for the mobile station is not permitted as the IoT service policy. A program to be executed by a computer.

Images