JP6632025B2 - Communication system, communication method, and program - Google Patents

Description

  The present invention relates to a communication system, a communication method, and a program, and particularly to a communication system, a communication 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 become widespread. The IoT service is implemented using, for example, 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 that provides the general service and the core network that provides the IoT service are separated from each other, and are independently provided. Operation is under consideration. By separating the core network, it becomes possible to design equipment etc. 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 packet transfer destination based on the MAC address or 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

  However, in networks constructed based on standards such as 3GPP (3rd Generation Partnership Project), various protocols are defined between node devices. Therefore, there is a problem in that when the packet is transferred, simply changing the IP address of the transmission destination does not match the information with the protocol defined between the node devices, and the packet cannot be transferred properly. .

  An object of the present invention is to provide a communication system, a communication method, and a program capable of appropriately distributing packets in a network constructed based on the 3GPP standard.

  The communication system according to the first aspect of the present invention includes a management device that manages identification information of a mobile station in association with identification information of a core network in which the mobile station is registered, and terminates an S1AP message transmitted from the eNB. And extracting, from the management device, identification information of the core network associated with the identification information of the mobile station included in the S1AP message from among the plurality of core networks, and extracting the MME located in the core network. And a gateway device for transmitting the S1AP message terminated to the gateway.

  A communication method according to a second aspect of the present invention is a management apparatus for terminating an S1AP message transmitted from an eNB and managing the mobile station identification information in association with the core network identification information in which the mobile station is registered. And identifying the core network identification information associated with the mobile station identification information included in the S1AP message from among the plurality of core networks, and terminating to the MME located in the core network. The above-mentioned S1AP message is transmitted.

  According to a third aspect of the present invention, there is provided a program for terminating a RANAP protocol message transmitted from an RNC, and managing a mobile station identification information in association with identification information of a core network in which the mobile station is registered. To identify the identification information of the core network associated with the identification information of the mobile station included in the RANAP protocol message from among the plurality of core networks, and to the SGSN located in the core network It is for causing a computer to transmit the terminated RANAP protocol message.

  According to the present invention, it is possible to provide a communication system, a communication method, and a program capable of appropriately distributing packets in a network constructed based on the 3GPP standard.

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. 10 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. 21 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 showing a processing flow when the UE according to the sixth embodiment completes packet communication. FIG. 21 is a diagram showing a flow of processing 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 in 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 a computer device that operates 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. The UE 40 is a general 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 perform 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 perform communication according to the S1AP.

  Subsequently, a configuration example of the gateway device 20 will be described. The gateway device 20 includes 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 determining unit 22 determines the terminal type of the UE 40 associated with the S1AP message. The S1AP message is a message used for managing the location information of the UE 40 and for controlling the call processing 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 whose source address has been converted to the MME 30 or the MME 32 determined according to the terminal type. For example, the MME 30 and the MME 32 manage the position 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. Furthermore, the gateway device 20 can distribute the S1AP message to a plurality of MMEs according to the terminal type of the UE 40.

  Further, 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 with the changed identification information of the transmission source to the MME, whereby the gateway device 20 allows the eNB 10 and the MME 30 or Even if it is arranged between the MME 32 and the S1AP message is terminated, the S1AP message can be transmitted normally. In other words, 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 is increasing 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 has a possibility of accommodating more terminals than a smartphone or the like in the future. 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 the control data for 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. Also, 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 destination of the Initial UE Message. The gateway device 20 determines the distribution destination of the Initial UE Message by 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, when receiving the 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 assigns MME-S1AP-id = B to MME-S1AP-id = D.

  Next, the gateway device 20 transmits a Downlink NAS Transport message with the source address 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, upon 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 MME 32.

  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 in which the Attach Complete message is multiplexed to the gateway device 20 (S25). Here, as in step S20, the gateway device 20 performs 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 Packets transmitted between the eNB 10 and the SGW are transmitted via the gateway device 20 in the same manner as control data. In this case, the gateway device 20 performs the translation of the address set in the Uplink / Downlink Packet as in steps S17 and S20.

  Next, the flow of processing when no communication is detected according to the second embodiment of the present invention will be described using 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. 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. 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 shown in FIG. 5 has the same configuration as the gateway device 20 shown in FIGS. 1 and 2, and thus a detailed description is omitted.

  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 execute call processing control on the UE 40. The SGSN 31 and the SGSN 33 transmit control data and user data regarding 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 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 SGSN.

  The SGSN for transmitting the control data for 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 that is a RANAP protocol message (S43). In other words, the gateway device 20 determines the destination of the Initial UE Message. The gateway device 20 determines the distribution destination of the Initial UE Message by using the information on the terminal type set in the Attach Request message included in the Initial UE Message. When the information indicating that the terminal is used for the IoT service is set in the terminal type, the gateway device 20 determines that the initial UE message is to be 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 replaces the source address 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 the 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, upon 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 3GPP, and thus detailed description is 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, also in the communication system according to the third embodiment of the present invention, the RANAP protocol message can be terminated and transferred 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 disposed 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, smart meter management services, traffic control services, services related to government agencies or emergency agencies, distribution management services, security provision services, inventory management services, and the like. 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 managing 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 that transmits 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 the 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 the information on the subscriber number and the 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 transmission 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 transmitting the UE 40.

  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, 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. 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.

  In addition, the UE 40 used for the IoT service may be a terminal dedicated to the IoT service, such as a smart meter or a vehicle-mounted terminal. Therefore, the IoT type may be registered in advance in the UE 40 used for the IoT service. 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. Thereby, 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.

  Also, 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 using 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. Since 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 can be omitted when the UE 40 performs communication. 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 at the time of 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 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 Attach process performed before the transmission of the user data regarding the UE 40 is performed, or the case where the non-communication state of the UE 40 is detected. 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. In other words, compared to the case where the subscriber data holding unit 92 holds the subscriber data regarding the UE 40, the time when the SGSN 31 executes the process of acquiring the subscriber data regarding the UE 40 from the HSS 64 is compared with the case where the UE 40 performs the packet communication. 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 regarding 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 relating to the UE 40 is not held.

  In addition, the IoT service policy may determine whether to permit the 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, if 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 IMSI (International Mobile Subscriber Identity), 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 regarding 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 executes 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.

  In step S116, when the authentication process for the UE 40 is completed, 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.

  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). Since the UE 40, the RNC 12, and the SGSN 31 hold PDP information on the UE 40, 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 ending 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 permit the SMS reception. (S135).

  Subsequently, a 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 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 embodiments, the present invention has been described as a hardware configuration, but the present invention is not limited to this. The present invention can also be realized by causing a CPU (Central Processing Unit) to execute a computer program for processing in a gateway device or other node devices.

  In the above example, the program can be stored and supplied to a computer using various types of non-transitory computer readable media. Non-transitory computer readable media include various types of tangible storage media. 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. The transitory computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.

  The present invention is not limited to the above 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 (12)

A management device that manages the mobile station identification information in association with the core network identification information in which the mobile station is registered,
terminating the S1AP message transmitted from the eNB, and extracting, from the plurality of core networks, identification information of the core network associated with the identification information of the mobile station included in the S1AP message from the management device; A gateway device for transmitting the terminated S1AP message to an MME located in the core network. A management device that manages the mobile station identification information in association with the core network identification information in which the mobile station is registered,
Terminate the RANAP protocol message transmitted from the RNC, and extract, from the management device, the identification information of the core network associated with the identification information of the mobile station included in the RANAP protocol message, from a plurality of core networks. A gateway device for transmitting the terminated RANAP protocol message to an SGSN located in the core network. The management device,
A first information management unit that holds a database that associates IoT type information indicating an IoT service provided by the core network with identification information of the core network;
The communication system according to claim 1, further comprising: a second information management unit that holds a database in which the identification information of the mobile station is associated with the IoT type information. The second information management unit includes:
The communication system according to claim 3, wherein identification information of the core network associated with identification information of the mobile station is updated according to a registration status of the mobile station in the core network. The management device,
A first information management unit that holds a database that associates IoT type information indicating an IoT service provided by the core network with identification information of the core network;
A communication unit that extracts the IoT type associated with the mobile station identification information transmitted from the gateway device from an HSS that holds a database that associates the mobile station identification information with the IoT type. The communication system according to claim 1 or 2, further comprising: The management device,
A first information management unit that holds a database that associates IoT type information indicating an IoT service provided by the core network with identification information of the core network;
A communication unit that extracts identification information of the core network associated with the IoT type information transmitted from the gateway device from the first information management unit, and transmits the extracted identification information of the core network to the gateway device. The communication system according to claim 1, comprising: The gateway device,
The source address set in the S1AP message transmitted from the eNB is changed from the identifier of the eNB to the first identifier of the gateway device, and the S1AP message with the changed source address is transmitted to the MME. The communication system according to claim 1, which performs the communication. The gateway device,
The source address set in the RANAP protocol message transmitted from the RNC is changed from the identifier of the RNC to the first identifier of the gateway device, and the RANAP protocol message with the changed source address is sent to the SGSN. The communication system according to claim 2, wherein the communication is transmitted to: Terminate the S1AP message sent from the eNB,
Using a management device that associates and manages identification information of a mobile station with identification information of a core network in which the mobile station is registered, from among a plurality of core networks, identification information of the mobile station included in the S1AP message Identifying identification information of the core network associated with
A communication method for transmitting the terminated S1AP message to an MME located in the core network. Terminate the RANAP protocol message sent from the RNC,
Using a management device that associates and manages the identification information of the mobile station with the identification information of the core network in which the mobile station is registered, from among the plurality of core networks, the identification of the mobile station included in the RANAP protocol message Identifying identification information of the core network associated with information;
A communication method, comprising transmitting the terminated RANAP protocol message to an SGSN located in the core network. Terminate the S1AP message sent from the eNB,
Using a management device that associates and manages identification information of a mobile station with identification information of a core network in which the mobile station is registered, from among a plurality of core networks, identification information of the mobile station included in the S1AP message Identifying identification information of the core network associated with
A program for causing a computer to transmit the terminated S1AP message to an MME located in the core network. Terminate the RANAP protocol message sent from the RNC,
Using a management device that associates and manages the identification information of the mobile station with the identification information of the core network in which the mobile station is registered, from among the plurality of core networks, the identification of the mobile station included in the RANAP protocol message Identifying identification information of the core network associated with information;
A program for causing a computer to transmit the terminated RANAP protocol message to an SGSN located in the core network.

Images