Relay device and method

Abstract

A relay device (30) is provided corresponding to one or a plurality of first user plane functions (UPF). The relay device (30) is provided with a control unit (33) and a transmit unit (31). The control unit (33) converts multicast data into unicast data addressed to one or a plurality of terminal devices. The transmit unit (31) transmits the unicast data to the one or a plurality of terminal devices.

Description

Technical Field

[0001] The present disclosure relates to a relay device and method.

Background Art

[0002] In Patent Document 1, as a technique for performing Multicast using LTE, for example, a technique for transmitting eMBMS data to one or more end nodes via unicast transmission is known.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In 3GPP (3rd Generation Partnership Project), studies on Multicast using 5G have been started.

[0005] In addition, studies on next-generation mobile communication systems that can be used by various entities according to regional needs and individual needs are also underway. For example, in the next-generation mobile communication system, in addition to the nationwide 5G service provided by mobile phone carriers, various entities such as local companies and local governments can build and use a network (local cellular network) flexibly and sporadically within their own buildings and sites.

[0006] Since the area where the local cellular network is provided is a limited area, it is less troublesome to identify devices that want to receive Multicast. Therefore, there is a high demand for Multicast in the local cellular network.

[0007] If there is a base station that supports the 3GPP Multicast standard, forwarding a single Multicast packet to this base station allows the base station to wirelessly transmit Multicast packets to multiple UEs. However, in local cellular networks, due to reasons such as the fact that systems are often built with low-cost Core Networks, base stations that do not support the 3GPP Multicast standard are frequently deployed.

[0008] Therefore, this disclosure provides a mechanism that enables multicast in a local cellular network where base stations that do not support the 3GPP multicast standard are deployed.

[0009] It should be noted that the above-mentioned problems or objectives are only one of several problems or objectives that can be solved or achieved by the various embodiments disclosed herein. [Means for solving the problem]

[0010] This disclosure provides a relay device. The relay device is provided in accordance with one or more first UPFs (User Plane Functions). The relay device comprises a control unit and a transmission unit. The control unit converts multicast data into unicast data destined for one or more terminal devices. The transmission unit transmits the unicast data to one or more of the terminal devices. [Brief explanation of the drawing]

[0011] [Figure 1] This figure shows an example of a 5G cellular network configuration. [Figure 2] This figure shows an example of a 4G cellular network configuration. [Figure 3] This is a schematic diagram illustrating an example of a cellular network. [Figure 4] This is a schematic diagram illustrating an example of a cellular network. [Figure 5]It is a diagram schematically showing an example of a cellular network. [Figure 6] It is a diagram schematically showing an example of a Private Network according to the first embodiment of the present disclosure. [Figure 7] It is a diagram showing a configuration example of a relay device functioning as Copy for UPF according to the first embodiment. [Figure 8] It is a diagram showing a configuration example of a relay device functioning as Copy for UE according to the first embodiment. [Figure 9] It is a diagram for explaining an example of Multicast performed in a Private Network according to the first embodiment. [Figure 10] It is a diagram showing an example of a Private Network according to the third embodiment of the present disclosure. [Figure 11] It is a sequence diagram showing the flow of Multicast processing according to the fifth embodiment of the present disclosure. [Figure 12] It is a diagram showing an example of a Multicast service according to the sixth embodiment of the present disclosure. [Figure 13] It is a diagram showing an example of a Multicast service according to the sixth embodiment of the present disclosure. [Figure 14] It is a diagram showing an example of a Multicast service. [Figure 15] It is a diagram for explaining Multicast according to the seventh embodiment of the present disclosure. [Figure 16] It is a sequence diagram showing the flow of Multicast according to the eighth embodiment of the present disclosure. [Figure 17] It is a sequence diagram showing the flow of an Attach Procedure. [Figure 18] It is a diagram showing an example of a protocol stack between a UE and a Core Network / HSS. [Figure 19] It is a diagram for explaining an application example of the technology of the present disclosure.

Embodiments for Carrying Out the Invention

[0012] The embodiments of the present disclosure will be described in detail with reference to the accompanying drawings below. In the present specification and drawings, components having substantially the same functional configuration are denoted by the same reference numerals, and redundant descriptions are omitted.

[0013] In addition, in the present specification and drawings, similar components of the embodiments may be distinguished by attaching different numbers or letters after the same reference numeral. However, when it is not necessary to particularly distinguish each of the similar components, only the same reference numeral is attached.

[0014] One or more of the embodiments (including examples and modifications) described below can be implemented independently. On the other hand, at least some of the plurality of embodiments described below may be implemented in appropriate combination with at least some of other embodiments. These plurality of embodiments may include different novel features from each other. Therefore, these plurality of embodiments may contribute to solving different purposes or problems from each other and may exhibit different effects from each other.

[0015] The description will be made in the following order. 1. First 1.1. Cellular Network 1.2. Related Technologies [[ID=二十二]] 3. First Embodiment 3.1. Private Network 3.2. Copy for UPF 3.3. Copy for UE 3.4. An Example of Multicast 4. Second Embodiment 5. Third Embodiment 6. Fourth Embodiment 7. Fifth Embodiment 8. Sixth Embodiment 9. Seventh Embodiment 10. Eighth Embodiment 11. Application Examples 12. Summary ​

[0016] <<1. Introduction>> <1.1. Cellular Network> The 3GPP (Third Generation Partnership Project) is considering and developing wireless access technologies such as LTE (Long Term Evolution) and NR (New Radio). For example, 3GPP TS23.401 and TS23.501 are considering and developing technologies related to cellular networks.

[0017] Note that LTE includes LTE-A (LTE-Advanced), LTE-A Pro (LTE-Advanced Pro), and EUTRA (Evolved Universal Terrestrial Radio Access). Similarly, NR includes NRAT (New Radio Access Technology) and FEUTRA (Further EUTRA). A single base station may manage multiple cells. In the following description, cells supporting LTE will be referred to as LTE cells, and cells supporting NR will be referred to as NR cells.

[0018] NR is the next generation (5G) of radio access technology (RAT), following LTE and other (4G) technologies. NR is a radio access technology that can support a variety of use cases, including eMBB (Enhanced Mobile Broadband), mMTC (Massive Machine Type Communications), and URLLC (Ultra-Reliable and Low Latency Communications). NR is being developed with the aim of creating a technical framework that addresses the usage scenarios, requirements, and deployment scenarios in these use cases.

[0019] Furthermore, terminal equipment connected to a cellular network (also called a mobile station, mobile station equipment, or terminal) is sometimes referred to as UE (User Equipment) or Terminal.

[0020] Figure 1 shows an example of a 5G cellular network configuration. Figure 2 shows an example of a 4G cellular network configuration.

[0021] A cellular network consists of a RAN (Radio Access Network) and a CN (Core Network). The RAN is the wireless system between base stations and terminals. The CN primarily handles authorization and session management when terminals connect to the network. In both 4G and 5G, the CN includes both a Control Plan Function and a User Plane Function.

[0022] In the 4G cellular network shown in Figure 2, various types of information related to the UE, such as subscriber information and information used to generate encryption keys, are stored on a server that functions as an HSS (Home Subscriber System).

[0023] In 5G, UDM (Unified Data Management) has similar functionality to HSS. Hereafter, we will refer to it as HSS, but the same principles apply to UDM as well.

[0024] The Control Plane Function retrieves information such as subscriber information of the accessed UE from the HSS and uses the retrieved subscriber information to determine whether the UE is allowed to connect to the network. The Control Plane Function also generates encryption keys for encryption. The UE is equipped with a SIM (Subscriber Identity Module) card. The SIM card stores a subscriber number called IMSI (International Mobile Subscriber Identity). For the UE to connect to the network, the UE's information, linked to the subscriber number on the SIM card installed in the UE, must be stored in the HSS.

[0025] For a UE to connect to the network, it requires the functionality of the CN's control plane (C-Plane). In the case of 4G, the MME (Mobility Management Function) shown in Figure 2 performs this role. In the case of 5G, the AMF (Access Management Function) or SMF (Session Management Function) shown in Figure 1 performs this role.

[0026] When a UE connects to a network and sends and receives data, the CN's U-Plane function is required. In the case of 4G, the S-GW (Serving Gateway) and P-GW (Packet Data Network Gateway) shown in Figure 2 perform this role. In the case of 5G, the UPF (User Plane Function) shown in Figure 1 performs this role.

[0027] 4G's P-GW and 5G's UPF act as gateways, marking the boundary between the CN and the general internet. When the CN is also deployed on the general internet, the CN-U, a User Plane Function of the Core Network (equivalent to the P-GW and UPF), can be considered a gateway positioned at the boundary between the CN and general applications.

[0028] <1.2. Related Technologies> <Mobile Edge Computing and Local Deployment of CN> By the way, in a cellular network, it is predicted that multiple CNs will be distributed and arranged. FIG. 3 is a diagram schematically showing an example of a cellular network. In the cellular network 1, multiple CNs (Core Network) are distributed and arranged. In FIG. 3, three CNs (1)-CN(3) are arranged.

[0029] Each CN includes a node of the Control Plane Function (CN-C) and a node of the User plane Function (CN-U). CN-C is communicatively connected to the HSS and determines whether a UE can connect to the network. CN-U transfers user data between the packet data network (PDN) or data network (DN) and the RAN.

[0030] In FIG. 3, a Core Network (CN(3)) is arranged near where the UE and the base station (BS: Base Station) are arranged. Thus, it is known that when a Core Network is arranged near where the UE and the base station (BS) are arranged, the delay required in the cellular part such as the RAN is reduced. Therefore, an increase in the Core Network arranged at the Edge of the Internet is expected.

[0031] In Figure 3, two CNs (2) and CN(3) are deployed at the Internet Edge as Edge Core Networks (Edge CNs). It is convenient to have a Master Center Core Network deployed on the Internet in addition to the Core Networks deployed at the Edge. In Figure 3, CN(1) is deployed as the Center Core Network (Center CN). When no Core Network is deployed at the Edge, management is performed using the Center CN. In the future, it is expected that, with the existence of Center CNs in this manner, numerous Core Networks (CNs) will be deployed at the Internet Edge in various locations around the world.

[0032] For example, it is conceivable that Core Networks will be deployed within LANs in factories, hospitals, and offices. In this case, at least the base stations will be located in local areas such as factories, hospitals, and offices. Furthermore, Core Networks may be deployed in local areas similar to base stations, or they may be deployed on the internet near those local areas. In any case, such local cellular systems require low-cost systems. These are sometimes referred to as Private 4G or Private 5G.

[0033] <UPFのScaling> One indicator of the capabilities of a User Plane Function implemented by UPF or SGW-PGW is the maximum throughput it can process. This could be, for example, the ability to process up to 100 Mbps of User Data (user plane data).

[0034] Let's assume the Core Network's UPF maximum throughput is 100Mbps. Also, let's assume one base station is connected to the Core Network, and this base station's capacity (maximum throughput) is 100Mbps. In this case, when one UE uses the network, this UE can enjoy a speed of 100Mbps. That is, this UE can send and receive data at 100Mbps.

[0035] On the other hand, as shown in Figure 4, suppose that 10 base stations with a capacity of 100 Mbps are connected to the Core Network, and one UE uses the network via one base station. Here, Figure 4 is a schematic diagram illustrating an example of a cellular network. In this case, the capacity of the Core Network's User Plane Function (S-GW, P-GW in Figure 4) becomes a bottleneck, and the throughput of each UE drops to a maximum of 10 Mbps.

[0036] As the number of base stations and UEs connected to the Core Network increases, the capabilities of the Core Network's User Plane Function need to be improved in order to maintain a predetermined throughput.

[0037] One way to improve (scale) the capabilities of the Core Network's U-Plane (User Plane) is to improve the capabilities of the computers that run the U-Plane functions. For example, if U-Plane processing is performed on a Virtual Machine in the Cloud data center, the capabilities of the U-Plane can be improved by replacing the Virtual Machine with a more powerful one. However, if the number of base stations increases tenfold, or the number of terminals increases tenfold, it is unlikely that replacing the capabilities of the computers (Virtual Machines) themselves will be sufficient to meet the increased demands for U-Plane capabilities.

[0038] Another way to improve U-Plane capabilities is to linearly increase the number of U-Plane functions. For example, in Figure 5, U-Plane processing is performed by 10 User Plane Function resources #1 to #10. Figure 5 is a schematic diagram illustrating an example of a cellular network.

[0039] As shown in Figure 5, having multiple User Plane Function resources perform U-Plane processing can improve U-Plane capabilities compared to having a single User Plane Function resource perform U-Plane processing.

[0040] Processing between the UE and the Core Network is performed by creating a communication conduit called a PDU session for each UE. Therefore, multiple U-Plane Functions (UPFs) can perform parallel processing for each PDU Session. Thus, it is desirable to prepare multiple U-Plane Functions as a way to improve (scale) the capabilities of the U-Plane.

[0041] <Private NetworkにおけるMulticast> As mentioned above, Private Networks are cellular services limited to specific geographical areas such as factories, hospitals, schools, and offices. There is a demand for broadcasting and multicasting within these local, private areas where Private Networks are provided.

[0042] Because private networks are provided in limited areas, it's less difficult to identify the devices that want to receive signals via multicast. Therefore, there's likely to be a high demand for multicast in private networks. For example, multicast can be used to efficiently control IoT devices within a private network.

[0043] Systems that dynamically manage the frequencies used for communication, such as SAS (Spectrum Access System), are considered to be well-suited for multicast. Such systems, for example, determine whether a predetermined frequency is available each time communication is required, and use that frequency for communication when it is available.

[0044] For example, a use case for a system like SAS could be used in a stadium to multicast goal highlights. In this case, SAS would, for instance, acquire the frequency to be used for communication and then multicast the goal highlights to tens of thousands of spectators in the stadium via a private network.

[0045] In a private network, broadcasting can be considered a special case of multicasting. Therefore, it is considered important to implement a mechanism for multicasting within a private network.

[0046] <Multicast using Internet protocols> Here, we will explain multicast using internet protocols. Multicast is a one-to-many communication service that provides a single packet to multiple recipients.

[0047] In IP (Internet Protocol) multicast, a single IP packet is generated and sent to multiple terminal devices. The Destination IP Address of a single IP packet contains a specific IP address reserved for multicast packets. These specific IP addresses may be, for example, 224.10.1.1 or 224.10.1.2.

[0048] Different multicast packets, such as those containing different content (e.g., a different program), will use different reserved IP addresses. For example, suppose the reserved IP address for one multicast packet is 224.10.1.1. In this case, a different multicast packet will use a different reserved IP address (e.g., 224.10.1.2).

[0049] Routers in the network route packets so that the desired multicast packets reach terminal devices that wish to receive them. Upon receiving a multicast packet, the terminal device checks the destination IP address of the received packet. If the received packet is the desired multicast packet, the terminal device accepts it. Conversely, if the received packet is not the desired multicast packet, the terminal device discards it.

[0050] Multicast, as defined as an internet function, cannot operate on cellular systems such as 4G and 5G. This is because packet routing using IP addresses is not performed for packets delivered to terminal devices within the cellular network.

[0051] Packets entering a cellular system from outside the network reach the UPF (User Plane Function), where they are placed into a communication conduit created using the GTP tunnel protocol, which is provided for each UE (User Entrant), and then transported to the UE. Thus, within a cellular system network, packets are not transported using IP addresses.

[0052] Therefore, it is difficult to implement multicast services using internet protocols in cellular systems.

[0053] Furthermore, in multicast using internet protocols, UEs participating in a multicast group notify the nearest router of their IP address using a protocol called IGMP (Internet Group Management Protocol). In the case of cellular networks, the nearest router is the UPF or the router behind the UPF (on the internet side).

[0054] However, multicast using internet protocols requires a special IP address to indicate multicast when sending data to the destination IP address. Therefore, UPF cannot include multicast packets within a GTP tunnel destined for a UE participating in a multicast group. Furthermore, there may be cases where there is no room to implement protocols like IGMP in IoT devices.

[0055] <Multicast according to the 3GPP MBMS standard> As mentioned above, it is difficult to implement multicast services using internet protocols in cellular systems. Therefore, during the 3GPP standardization process, multicast operating within cellular networks was standardized (3GPP TS23.246 MBMS (Multimedia Broadcast Multicast Service)).

[0056] In this standard's multicast, once a multicast packet reaches each base station, the base station transmits one multicast packet over the wireless section. Multiple UEs that wish to receive the multicast packet simultaneously receive the multicast packet transmitted by the base station. This enables multicast in cellular systems.

[0057] This method allows multicasting in both wired and wireless sections, but in order to use this method, the base station and the Core Network must implement the 3GPP MBMS protocol.

[0058] In Private 5G and Private 4G, which are examples of Private Networks mentioned above, systems are often built using small, low-cost base stations and low-cost core networks. It is likely that such small base stations and core networks often do not support MBMS as defined by 3GPP.

[0059] Therefore, in private networks, there is a need to implement multicast using equipment that does not support the full-spec multicast mechanism standardized by 3GPP.

[0060] <<2. Overview of the proposed technology>> As mentioned above, it is difficult to use the multicast defined for the internet in a private network. Furthermore, multicast defined for cellular networks, even in 4G, is often not actually implemented in small base stations or small core networks. Therefore, it is difficult to use multicast defined for cellular networks in private networks built with these small base stations and small core networks.

[0061] Furthermore, as mentioned above, in a private network, it is possible to keep the processing capacity of a single UPF low by deploying multiple UPFs (User Plane Functions; in 4G, a pair of S-GW and P-GW) in the Core Network. In a private network where multiple UPFs are deployed in this way, a method is required to determine which UPF to copy and forward multicast packets to.

[0062] Furthermore, in order to use multicast on a private network, a mechanism is required to multicast multicast packets that have arrived at the UPF to multiple UEs.

[0063] As mentioned above, if there is a base station that supports the 3GPP Multicast standard, forwarding a single Multicast packet to this base station allows the base station to wirelessly transmit Multicast packets to multiple UEs. However, in private networks, it is likely that base stations that do not support the 3GPP Multicast standard will be deployed. Therefore, in this proposed technology, a separate packet is prepared for each UE that wishes to receive Multicast packets beyond the UPF (on the internet side). To achieve this, in this proposed technology, a single Multicast packet is copied according to the number of individual UEs, and the individual IP addresses of each UE are reassigned to each copy.

[0064] This individual UE's IP address is used not so much for routing multicast packets, but rather for UPF to place multicast packets into the GTP tunnel. In other words, UPF sends multicast packets to the UE by placing them into the GTP tunnel based on the UE's IP address. Therefore, the proposed technology has the characteristic of determining whether an IP address has been assigned to the UE sending the multicast packet.

[0065] Here, we will briefly explain the overview of the Multicast process, including the conventional technologies mentioned above.

[0066] (Internet Protocol Multicast flow) Step 1: The UE notifies the nearest router of its desire to receive multicast packets by using IGMP to inform it of its own IP address. At this time, the UE also notifies the router of which multicast channel it wants to receive multicast packets from.

[0067] Step 2: Routers that need to copy the multicast packets will copy them in order to forward the multicast packets to the network where the packets identified in Step 1 reside. The IP address reserved for the multicast packets will be used until the end (when sending the multicast packets to the UE).

[0068] Step 3: The UE receives the incoming multicast packet if it is one that it intended to receive.

[0069] (The multicast process of the 3GPP standard (4G)) Step 1: The UE notifies the Core Network that it wishes to receive multicast packets. At this time, the UE also notifies the Core Network of which multicast channel's multicast packets it wishes to receive.

[0070] Step 2: In the Core Network section, the multicast packets identified in Step 1 are forwarded to the network where they exist. Routers that need to copy multicast packets will do so. The IP address reserved for the multicast packets will be used until the end. Note that multicast packets are delivered directly to the base station without using UPF.

[0071] A multicast packet delivered to the base station is transmitted from the base station as a single multicast packet in the wireless section and received simultaneously by multiple UEs.

[0072] Step 3: The UE receives the incoming multicast packet if it is one that it intended to receive.

[0073] Thus, multicast is achieved by using a Core Network and base stations that support the 3GPP standard (4G) multicast.

[0074] While a standard for multicast exists for 4G, one has not yet been created for 5G.

[0075] (The Multicast flow of the proposed technology) Step 1: The UE notifies the Core Network that it wishes to receive multicast packets. At this time, the UE also notifies the Core Network of which multicast channel's multicast packets it wishes to receive.

[0076] Step 2: To forward the multicast packets identified in Step 1 to the network where they exist, routers located in limited areas (an example of a relay device described later) copy the packets, rather than a specific router. Also, instead of using the IP address reserved for multicast packets until the end, the IP address is reassigned before the UPF, for example, to the IP address assigned to each UE by the router copying the packets. Note that in the wireless section, multicast packets are copied just before the UPF in order to prepare a packet for each UE. The copied packets are sent to the UE via the GTP tunnel.

[0077] Step 3: The UE receives the incoming multicast packet if it is one that it intended to receive.

[0078] Thus, in the proposed Multicast technology, Multicast packets are delivered using IP addresses assigned for Multicast up to the router immediately preceding the UPF. This differs from conventional Internet protocol Multicast in that the location of this router is determined considering cost and the location of the UPF.

[0079] Furthermore, the router immediately preceding the UPF copies the multicast packets to prepare packets for each UE. At this time, the IP address assigned for multicast is reassigned to the individual UE's IP address. The router copying the multicast packets checks whether an individual IP address has been assigned to the UE and obtains the individual UE's IP address.

[0080] Thus, the router (an example of a relay device) related to this proposed technology is a device that copies multicast packets for UEs (Copy for UE). In other words, the router related to this proposed technology converts multicast packets (an example of multicast data) into packets destined for multiple UEs (terminal devices) (an example of unicast data), and sends the converted packets to the multiple UEs. The router related to this proposed technology is deployed for one or more UPFs.

[0081] <<3. First Embodiment>> In this case, for a UE belonging to a private network to receive the Multicast service, one possible method is to launch an Application from the UE, connect to the network's Multicast server, and then register to receive the Multicast service. However, this method is complicated, and a simpler method is needed.

[0082] For example, one possible method is to group UEs that want to receive the multicast service by having them register in advance using IDs associated with the UE's SIM, such as IMSI or SUPI. However, even if UEs that want to receive the multicast service are grouped together, in order for the UEs to actually receive the multicast service, information about the UPF to which the UE belongs and information about the UE's IP address are required. This information is used to route multicast packets.

[0083] Normally, information about the UPF to which the UE belongs and information about the UE's IP address must be provided by the UE accessing the server that provides the Network-side Multicast Service. However, this method of providing information by the UE is cumbersome.

[0084] Multicast can have multiple channels (programs, sessions). Therefore, to distinguish between these multiple channels, an entity is ultimately needed to observe the source address of the multicast packets. Placing such an entity at every point where multicast packets arrive would increase the number of entities and thus the cost, making it difficult to implement.

[0085] Therefore, by knowing the UPF used by each UE, or the UPF used by the multicast packet, it may be possible to more easily configure a private network by determining the UPF carrying the multicast packet. The UPF used by the multicast packet can be determined by monitoring the Source IP Address of the multicast packet.

[0086] <3.1. Private Network> Figure 6 is a schematic diagram showing an example of a Private Network according to the first embodiment of this disclosure.

[0087] The Private Network shown in Figure 6 is a virtual private network in which some functions of the Core Network are installed on the LAN (Local Area Network) (On-Premise), and some functions of the Core Network are installed on the internet (On-Cloud).

[0088] In Figure 6, multiple UEs (UE1-UE5), base stations (Base station #1-#10), and a portion of the UPF (UPF10_1, 10_2) are installed on the LAN. The remaining UPFs (UPF10_3-10_32), relay devices (Copy for UPF20, Copy for UE30), and the Control Plane Function are installed on the internet, for example, in a data center of a cloud provider.

[0089] [UPF] In the Private Network according to this embodiment, the UPF to which the UE that sends multicast packets belongs is limited. Specifically, UPF10 (Uplink UPF, an example of a second UPF) that processes the uplink of multicast packets is limited.

[0090] Furthermore, in the Private Network according to this embodiment, the UPF10 to which the UE receiving the multicast packets belongs is limited in its configuration. That is, the UPF that processes the Downlink of multicast packets (Downlink UPF, an example of a first UPF) is limited in its configuration.

[0091] The network is aware of the limited Uplink UPF and Downlink UPF. UEs sending multicast packets are linked in their subscriber files (Subscriber Information, Association between UE and UPF) to use their limited Uplink UPF. Similarly, UEs receiving multicast packets are linked in their subscriber files to use their limited Downlink UPF.

[0092] In this context, Uplink UPF refers to a UPF that transmits multicast packets via the uplink. That is, for normal traffic other than multicast packets, the Uplink UPF handles both uplink and downlink processing. Similarly, Downlink UPF refers to a UPF that receives multicast packets via the downlink. That is, for normal traffic other than multicast packets, the Downlink UPF handles both uplink and downlink processing.

[0093] Table 1 shows the types of packets processed by UPF10_1 to 10_32. The UPF IDs shown in Table 1 are information that identifies the UPF. For example, the UPF IDs shown in Table 1 correspond to the last digits of UPF10_1 to 10_32 shown in Figure 7. As shown in Table 1, UPF10_1, 10_2, 10_4, 10_7, ..., 10_32 process the uplink and downlink of unicast packets. UPF10_3 processes the uplink of multicast packets. UPF10_5 processes the downlink of multicast packets. UPF10_6 processes the downlink of multicast packets and the uplink and downlink of unicast packets.

[0094] [Table 1]

[0095] In other words, in UPF10_1 to 10_32 shown in Figure 6, UPF10_3 is the Uplink UPF, and UPF10_5 and 10_6 are the Downlink UPF.

[0096] The UPF settings shown in Table 1 are performed by the Resource Management Function (not shown in the diagram).

[0097] [Copy for UPF] Furthermore, in the Private Network according to this embodiment, a relay device (Copy for UPF20, an example of a second relay device) is provided to determine which UPF to return multicast packets output from the Uplink UPF to. A Copy for UPF20 is provided to correspond to one or more Uplink UPFs.

[0098] As described above, in the Private Network according to this embodiment, UPF10_3 (Uplink UPF), to which the UE that sends multicast packets belongs, is exclusively deployed. Therefore, the entity (Copy for UPF20) that determines which UPF10 to return multicast packets output from the Uplink UPF to only needs to be placed near the Uplink UPF. Thus, the number of Copy for UPF20 instances can be kept to the absolute minimum.

[0099] Copy for UPF20 checks the Destination IP Address of packets output from the Uplink UPF. If the Destination IP Address is a multicast IP Address, Copy for UPF20 identifies the packet output from the Uplink UPF as a multicast packet. Examples of multicast IP Addresses include 224.0.0.0.

[0100] Copy for UPF20 sends the identified multicast packet to the UPF10 (Downlink UPF) to which the UE receiving the multicast packet belongs. If there are multiple Downlink UPFs, Copy for UPF20 duplicates the multicast packet and sends it to each Downlink UPF.

[0101] For example, in the example in Figure 6, Copy for UPF20 duplicates the multicast packet and sends it to UPF10_5 and 10_6.

[0102] In this case, Copy for UPF20 may reassign an IP address to the UPF10 as the Destination IP Address for the duplicated multicast packets. Alternatively, instead of reassigning the Destination IP Address, Copy for UPF20 may specify the IP address of the Downlink UPF in its routing table so that the duplicated multicast packets are directed to the target Downlink UPF. In practice, it is desirable that the IP address of UPF10 that Copy for UPF20 sets in its routing table be the IP address of the entity immediately preceding UPF10 (the relay device, Copy for UE30). This is because, as will be explained later, the multicast packets are converted into packets destined for the UE in Copy for UE30.

[0103] [Copy for UE30] In the Private Network according to this embodiment, a relay device (Copy for UE30) is provided to determine which UE should receive the multicast packets output from Copy for UPF20. Copy for UE30 is provided to correspond to one or more Downlink UPFs.

[0104] As described above, in the Private Network according to this embodiment, UPF10_5 and 10_6 (Downlink UPF), to which the UE receiving the multicast packets belongs, are exclusively deployed. Therefore, the entity (Copy for UE30) for determining which UE to send the multicast packets output from Copy for UPF20 to only needs to be placed near the Downlink UPF. As a result, the number of Copy for UE30 units can be kept to the absolute minimum.

[0105] Copy for UE30 converts multicast packets output from Copy for UPF20 into unicast packets destined for UEs belonging to the Downlink UPF that receive multicast packets. Copy for UE30 converts multicast packets to unicast packets by assigning the UE's IP address as the destination address to the multicast packet. If there are multiple UEs belonging to the Downlink UPF, Copy for UE30 duplicates the multicast packet for each UE and converts it into a unicast packet. Copy for UE30 sends the converted unicast packets to the UEs via the Downlink UPF.

[0106] Note that while Figure 6 shows a case where one Copy for UE30 is provided for one Downlink UPF, a Copy for UE30 may be provided for each of multiple Downlink UPFs. A Copy for UE30 is deployed corresponding to one or more Downlink UPFs.

[0107] Here, Copy for UPF20 replicates multicast packets according to the number of Copy for UE30 instances. As described above, in the Private Network according to this embodiment, the number of installed Copy for UE30 instances can be suppressed by limiting the deployment of Downlink UPF instances. In other words, the number of multicast packets replicated by Copy for UPF20 can be suppressed, and the processing load on Copy for UPF20 can be reduced.

[0108] Furthermore, it is preferable that the Uplink UPF and Downlink UPF have different UPF10 codes. The Downlink UPF is flooded with traffic from multicast packets duplicated for multiple UEs. Since the Uplink multicast packets are copied and received by many UEs, packet loss due to traffic congestion in the Uplink multicast packets has a significant impact. Therefore, it is preferable that the Uplink UPF and Downlink UPF have different UPF10 codes. In particular, when the Core Network is small and the processing load of each UPF is low, it is better for the Uplink UPF and Downlink UPF to have different UPF10 codes.

[0109] <3.2. Copy for UPF> Figure 7 shows an example configuration of a relay device that functions as Copy for UPF according to the first embodiment. Copy for UPF20 copies multicast packets received from Uplink UPF and relays them to Copy for UE30. Hereinafter, the relay device that functions as Copy for UPF20 will also be simply referred to as Copy for UPF20.

[0110] Copy for UPF20 comprises a communication unit 21, a storage unit 22, and a control unit 23. Note that the configuration shown in Figure 7 is a functional configuration, and the hardware configuration may differ. Furthermore, the functions of Copy for UPF20 may be implemented in a distributed manner across multiple physically separated configurations. For example, Copy for UPF20 may be composed of multiple server devices.

[0111] The communication unit 21 is a communication interface for communicating with other devices. The communication unit 21 may be a network interface or an equipment connection interface. For example, the communication unit 21 may be a LAN (Local Area Network) interface such as a NIC (Network Interface Card), or a USB interface consisting of a USB (Universal Serial Bus) host controller, USB port, etc. Furthermore, the communication unit 21 may be a wired interface or a wireless interface. The communication unit 21 functions as a means of communication for Copy for UPF20. The communication unit 21 is capable of communicating with multiple Core Networks provided in the cellular network 1.

[0112] The memory unit 22 is a data read / write storage device such as DRAM (Dynamic Random Access Memory), SRAM (Static Random Access Memory), flash memory, or hard disk. The memory unit 22 functions as a storage means for Copy for UPF20. The memory unit 22 stores various programs. The memory unit 22 also stores various data.

[0113] The control unit 23 is a controller that controls each part of Copy for UPF20. The control unit 23 is implemented by a processor such as a CPU (Central Processing Unit) or MPU (Micro Processing Unit). For example, the control unit 23 is implemented by the processor executing various programs stored in the internal memory of Copy for UPF20 using RAM (Random Access Memory) or the like as a working area. The control unit 23 may also be implemented by an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array). CPUs, MPUs, ASICs, and FPGAs can all be considered controllers.

[0114] The control unit 23 comprises a replication unit 231 and a setting unit 232. Each block constituting the control unit 23 (the replication unit 231 and the setting unit 232) is a functional block that represents the function of the control unit 23. These functional blocks may be software blocks or hardware blocks. For example, each of the above-mentioned functional blocks may be a single software module implemented in software (including a microprogram), or a single circuit block on a semiconductor chip (die). Of course, each functional block may also be a single processor or a single integrated circuit. The configuration of the functional blocks is arbitrary. The control unit 23 may also be composed of functional units different from the above-mentioned functional blocks.

[0115] The replication unit 231 replicates the multicast packets received from the Uplink UPF via the communication unit 21, generating multiple multicast packets. The replication unit 231 replicates the same number of multicast packets as the number of Downlink UPFs that send multicast packets.

[0116] The configuration unit 232 sets the destination for the multicast packets duplicated by the replication unit 231. As described above, the configuration unit 232 sets Copy for UE30 as the destination for multicast packets by specifying the IP address of Copy for UE30 in the routing table, for example.

[0117] The control unit 23 transmits the multicast packets duplicated by the duplication unit 231 to the destination set by the setting unit 232 via the communication unit 21.

[0118] <3.3.Copy for UE> Figure 8 shows an example configuration of a relay device that functions as a Copy for UE30 according to the first embodiment. The Copy for UE30 copies the multicast packets received from the Copy for UE30 and relays them to the UE via Downlink UPF. Hereinafter, the relay device that functions as a Copy for UE30 will also be simply referred to as Copy for UE30.

[0119] Copy for UE30 comprises a communication unit 31, a storage unit 32, and a control unit 33. Note that the configuration shown in Figure 8 is a functional configuration, and the hardware configuration may differ. Furthermore, the functions of Copy for UE30 may be implemented in a distributed manner across multiple physically separated configurations. For example, Copy for UE30 may be composed of multiple server devices.

[0120] The communication unit 31 is a communication interface for communicating with other devices. The communication unit 31 may be a network interface or a device connection interface. For example, the communication unit 31 may be a LAN (Local Area Network) interface such as a NIC (Network Interface Card), or a USB interface consisting of a USB (Universal Serial Bus) host controller, USB port, etc. Furthermore, the communication unit 31 may be a wired interface or a wireless interface. The communication unit 31 functions as a means of communication for Copy for UE30. The communication unit 31 is capable of communicating with multiple Core Networks provided in the cellular network 1.

[0121] The memory unit 32 is a data read / write storage device such as DRAM (Dynamic Random Access Memory), SRAM (Static Random Access Memory), flash memory, or hard disk. The memory unit 32 functions as a storage means for Copy for UE30. The memory unit 32 stores various programs. The memory unit 32 also stores various data.

[0122] The control unit 33 is a controller that controls the various parts of Copy for UE30. The control unit 33 is implemented by a processor such as a CPU (Central Processing Unit) or an MPU (Micro Processing Unit). For example, the control unit 33 is implemented by the processor executing various programs stored in the internal memory of Copy for UE30 using RAM (Random Access Memory) or the like as a working area. The control unit 33 may also be implemented by an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array). CPUs, MPUs, ASICs, and FPGAs can all be considered controllers.

[0123] The control unit 33 comprises a duplication unit 331, a setting unit 332, and a transmission unit 333. Each block constituting the control unit 33 (duplication unit 331, setting unit 332, and transmission unit 333) is a functional block that represents the function of the control unit 33. These functional blocks may be software blocks or hardware blocks. For example, each of the above-mentioned functional blocks may be a single software module implemented in software (including a microprogram), or a single circuit block on a semiconductor chip (die). Of course, each functional block may also be a single processor or a single integrated circuit. The configuration of the functional blocks is arbitrary. The control unit 33 may also be composed of functional units different from the above-mentioned functional blocks.

[0124] The replication unit 331 replicates the multicast packets received from Copy for UPF20 via the communication unit 21, generating multiple multicast packets. The replication unit 331 replicates the same number of multicast packets as the number of UEs that send multicast packets.

[0125] The configuration unit 332 sets the destination for the multicast packets duplicated by the replication unit 331. For example, the configuration unit 332 sets a multicast packet destination from among the UEs associated with the Downlink UPF that have already obtained an IP address. Note that UEs attached to cellular network 1 have already obtained an IP address.

[0126] Specifically, the configuration unit 332 sets the UE, whose IP address has already been obtained, as the destination for the multicast packets by rewriting the UE's IP address as the Destination Address of the multicast packets duplicated by the replication unit 331. In this way, packets whose destinations are set by the configuration unit 332 can also be said to be unicast packets destined for the UE. Thus, the configuration unit 332 is a conversion unit that converts multicast packets into unicast packets destined for the UE.

[0127] The transmitting unit 333 transmits the Unicast packet converted by the configuration unit 332 to the Downlink UPF via the communication unit 31. As a result, the Unicast packet is placed in the corresponding UE's GTP tunnel at the Downlink UPF and transmitted to the UE via the base station.

[0128] <3.4. Example of Multicast> An example of multicasting performed in a private network according to the first embodiment will be explained using Figure 9. Figure 9 is a diagram illustrating an example of multicasting performed in a private network according to the first embodiment.

[0129] As shown in Figure 9, UE1 sends a multicast packet via the uplink. The multicast packet sent by UE1 is then sent to the uplink UPF, UPF10_3, via Base station #1. Copy for UPF20, located downstream of UPF10_3, duplicates the multicast packet received by UPF10_3 and sends it to the downlink UPFs, UPF10_5 and 10_6. More specifically, Copy for UPF20 sends the multicast packet to Copy for UE30_1 and 30_2, which correspond to UPF10_5 and 10_6, respectively.

[0130] In the example in Figure 9, Copy for UE30_1 duplicates the multicast packet. Copy for UE30_1 converts the duplicated multicast packet into a unicast packet destined for UE2 and UE3, which are associated with UPF10_5. Copy for UE30_1 then sends the converted unicast packet to UPF10_5. As a result, the unicast packet is placed in the GTP tunnel corresponding to UE2 and UE3 at UPF10_5 and sent to UE2 and UE3 via Base station #10.

[0131] Although not shown in the diagram, Copy for UE30_2 similarly converts multicast packets into unicast packets destined for UE4 and UE5, which are associated with UPF10_6. Copy for UE30_2 then sends the converted unicast packets to UPF10_6. As a result, the unicast packets are placed in the GTP tunnels corresponding to UE4 and UE5 at UPF10_6 and sent to UE4 and UE5 via Base station #10.

[0132] This allows UE2-UE5 to receive packets with the same content as the multicast packet sent by UE1.

[0133] Furthermore, UE1, which sends multicast packets, is specified in its subscriber file (Subscriber Information, Association between UE and UPF) to use UPF10_3, which is the Uplink UPF. UE2 and UE3, which receive multicast packets, are specified in their subscriber files to use UPF10_5, which is the Downlink UPF. UE4 and UE5, which also receive multicast packets, are specified in their subscriber files to use UPF10_6, which is the Downlink UPF.

[0134] As mentioned above, UPF10_3, which handles the uplink of multicast packets, and UPF10_5 and 10_6, which handle the downlink, are different UPF10s. By limiting the UPF10 that handles the uplink of multicast packets in this way, the number of Copy for UPF20 in the Private Network shown in Figure 9 can be reduced to one. Similarly, by limiting the UPF that handles the downlink of multicast packets, the number of Copy for UE30 in the Private Network shown in Figure 9 can be reduced to two.

[0135] Furthermore, Copy for UPF20 does not need to be aware of which UE wants to receive the multicast packets; it simply needs to forward the multicast packets to the pre-specified 10_5 and 10_6. Therefore, in the Private Network according to the first embodiment, the processing load of Copy for UPF20 can be reduced.

[0136] Thus, in the Private Network according to the first embodiment, multicast can be achieved without increasing the processing capacity of UPF10 by limiting the UPF10 that processes multicast packets. Furthermore, the number of relay devices (Copy for UPF20, Copy for UE30) deployed in the Private Network can be reduced, thereby suppressing the increase in the scale of the Private Network and suppressing the increase in the cost of constructing the Private Network.

[0137] As mentioned above, in Multicast, multiple Channels (programs, sessions) may be used simultaneously. In this case, Copy for UPF20 determines which Downlink UPF to copy and forward Multicast packets to for each Channel. Therefore, as shown in Table 2, Copy for UPF20 stores the correspondence between Channels and the Downlink UPFs to which Multicast packets are forwarded. This correspondence is stored, for example, in the storage unit 22 of Copy for UPF20.

[0138] [Table 2]

[0139] In the example in Table 2, Copy for UPF20 stores the Multicast Channel ID in association with the Downlink UPF ID being used. The Multicast Channel ID is information that identifies the Multicast channel, and the Downlink UPF ID is information that identifies the Downlink UPF. For example, the Downlink UPF IDs shown in Table 2 correspond to the last digits of UPF10_1 to 10_32 shown in Figure 7.

[0140] Table 2 shows, for example, that a Channel with Multicast Channel ID "1" corresponds to UPF10_5. Also, a Channel with Multicast Channel ID "3" corresponds to UPF10_6. A Channel with Multicast Channel ID "4" corresponds to both UPF10_5 and 10_6.

[0141] For example, if Copy for UPF20 receives a multicast packet with a multicast channel ID of "1", it forwards the received multicast packet to UPF10_5. If Copy for UPF20 receives a multicast packet with a multicast channel ID of "3", it forwards the received multicast packet to UPF10_6. If Copy for UPF20 receives a multicast packet with a multicast channel ID of "4", it duplicates the received multicast packet and forwards it to UPF10_5 and 10_6.

[0142] In the first embodiment, by limiting the UPF to which the UE sending the multicast packet belongs to the Uplink UPF, the number of Copy for UPF20 that determine the destination of the multicast packet output from the Uplink UPF can be reduced.

[0143] Furthermore, by limiting the UPF10 to which the UE receiving the multicast packets belongs to the Downlink UPF, the number of multicast packets duplicated by Copy for UPF20 can be reduced.

[0144] Furthermore, by separating the Uplink UPF that sends multicast packets from the Downlink UPF that receives multicast packets, it is possible to suppress the degradation of multicast packet quality.

[0145] <<4. Second Embodiment>> In the first embodiment, multiple UEs were assumed to receive multicast packets simultaneously, but this is not limited to this. For example, priorities may be assigned to multiple UEs so that they receive multicast packets in an order according to their priorities. The case in which priorities are assigned to multiple UEs will be described in the second embodiment.

[0146] Multicast packets contain control information that controls multiple devices (UEs), and the same control information may be transmitted to multiple devices via multicast. In this case, the importance of the multiple devices may differ, and there is a need to send the control information to the device with the highest importance first.

[0147] As described above, the Private Network has multiple Downlink UPFs. Therefore, in the second embodiment, for example, the Resource management Function sets the priority for sending multicast packets to the Downlink UPFs. Then, high-priority UEs are associated with high-priority Downlink UPFs, and low-priority UEs are associated with low-priority Downlink UPFs.

[0148] For example, let's assume there are few high-priority UEs and many low-priority UEs. Also, let's assume that UPF10_5 is a high-priority Downlink UPF and UPF10_6 is a low-priority Downlink UPF. In this case, a small number of high-priority UEs are subordinate to UPF10_5, and a large number of low-priority UEs are subordinate to UPF10_6. By sending multicast packets via UPF10_5 with priority over UPF10_6, we can achieve multicast with assigned priorities.

[0149] For example, in addition to equipment control information, a possible use case is to check video data captured by a camera in real time during filming. In this case, it is desirable that the film director, for instance, receives video data in multicast packets more reliably than other staff members. In this case, the UE used by the film director may be given higher priority, while the UE used by other staff members may be given lower priority.

[0150] Another possible use case is to multicast the match proceedings from the stadium to the stadium spectators. For example, goal highlights from a match could be multicast to the stadium spectators. In this case, the priority of multicasting could be set according to the type of ticket the spectator has. For example, UEs of spectators with expensive tickets could be given a higher priority for multicasting, while UEs of spectators with cheaper tickets could be given a lower priority.

[0151] In this case, for example, the number of UEs belonging to high-priority Downlink UPFs is reduced, and the number of UEs belonging to low-priority Downlink UPFs is increased. Note that UEs belonging to high-priority Downlink UPFs are UEs with high multicast priority set, and UEs belonging to low-priority Downlink UPFs are UEs with low multicast priority set.

[0152] When a Downlink UPF has a large number of UEs, the number of multicast packets to be duplicated increases, increasing the processing load on the Downlink UPF and thus reducing its throughput. High-priority Downlink UPFs can mitigate this throughput reduction by having fewer UEs, and can send packets to high-priority UEs more quickly.

[0153] While this explanation describes setting priorities for each Downlink UPF, priorities can also be set within a single Downlink UPF by determining which UEs receive which packets first. For example, if tens of thousands of UEs are associated with a single Downlink UPF, even if they are associated with the same Downlink UPF, the order in which packets are sent can significantly affect the time it takes for these packets to reach their destinations. Therefore, even within a single Downlink UPF, setting priorities for each UE allows for priority packet delivery to important UEs, such as those with high ticket types. The transmission order within a Downlink UPF corresponds to the packet generation order in Copy for UE30, which sends packets to the Downlink UPF.

[0154] Table 3 shows the correspondence between UEs and their priorities when priorities are set for each UE in a single Downlink UPF. The correspondence shown in Table 3 is maintained, for example, by Copy for UE30, which generates packets in the order according to the UE's priority.

[0155] [Table 3]

[0156] For example, as shown in Table 3, Copy for UE30 stores a correspondence between the UE ID and the priority in Copy for UE30. The UE ID is information that identifies the UE. The priority in Copy for UE30 is information that indicates the order in which packets are generated, and in Table 3, it is divided into two types: "High" and "Low". Note that in Table 3, the number of UEs associated with one Copy for UE30 (Downlink UPF) is 128, but this is just an example, and the number of UEs associated with one Copy for UE30 (Downlink UPF) may be more or less than 128.

[0157] In the example above, the number of UEs associated with a Downlink UPF is changed according to the Downlink UPF's priority, but this is not limited to this. For example, the order in which multicast packets are generated and sent by Copy for UPF20 may be changed according to the Downlink UPF's priority. For example, Copy for UPF20 may duplicate and send multicast packets in order from the Downlink UPF with the highest priority.

[0158] In this case, Copy for UPF20 maintains a correspondence between the Downlink UPF and its priority. Table 4 shows the correspondence between the Downlink UPF and its priority. The correspondence shown in Table 4 is maintained by, for example, Copy for UPF20.

[0159] [Table 4]

[0160] As shown in Table 4, Copy for UPF20 maintains a correspondence between, for example, the UPF ID and the priority between UPF10s. The UPF ID is information that identifies the UPF10. The priority between UPF10s is the priority at which Copy for UPF20 sends multicast packets. The priority between UPF10s is set for Downlink UPFs. In Table 4, the priority of UPF10_5 is "High" and the priority of UPF10_6 is "Low". Therefore, Copy for UPF20 duplicates and sends multicast packets destined for UPF10_5 with higher priority than UPF10_6.

[0161] There are three ways to set the priority as described above.

[0162] (1) Set priority by changing the number of UEs assigned to the Downlink UPF for Multicast.

[0163] For example, by reducing the number of UEs assigned to a Downlink UPF for multicast, the priority of the UEs assigned to that Downlink UPF is set higher. For instance, one high-priority UE might use one Downlink UPF, while ten low-priority UEs might use one Downlink UPF. This allows high-priority UEs to receive packets with priority over low-priority UEs.

[0164] (2) In Copy for UE30, priority is set by copying and sending multicast packets for higher-priority UEs first.

[0165] (3) Use Copy for UPF to set priority by copying and sending the Multicast Packet for UPF, which has a higher priority, first.

[0166] In addition to the above, separating Uplink UPF and Downlink UPF can also protect important multicast content. For example, suppose a Contents Provider (see UE1 in Figure 7) uploads multicast content (multicast packets) to the network using Uplink UPF (see UPF10_3 in Figure 7). In this case, as mentioned above, the Uplink UPF should not be allowed to pass downlink traffic for multicast. This protects important multicast content.

[0167] Furthermore, the Private Network Multicast related to the technology disclosed herein may be referred to as semi-multicast. Therefore, the prioritization of the Multicast as described above is effective.

[0168] <<5. Third Embodiment>> In the first and second embodiments, UE1 uploaded the multicast packets, but this is not limited to this. For example, a multicast Contents Center may be established within the Private Cellular Network, and this Center may transmit the multicast packets. Such a case will be described as the third embodiment.

[0169] Figure 10 is a diagram showing an example of a Private Network according to the third embodiment of this disclosure. The Private Network shown in Figure 10 has the same configuration as the Private Network shown in Figure 7, except that it has a Multicast Contents Center 40.

[0170] As shown in Figure 10, the Multicast Contents Center 40 generates a multicast packet and sends it to the Copy for UPF 20. In this embodiment, the Copy for UPF 20 may be located near the Multicast Contents Center 40, rather than near the Uplink UPF. The Copy for UPF 20 forwards the received multicast packet to the Downlink UPF.

[0171] Thus, Copy for UPF20 may receive multicast packets from Multicast Contents Center40.

[0172] It should be noted that, although it is assumed here that the Multicast Contents Center 40 generates multicast packets, this is not the only way. The Multicast Contents Center 40 may also receive multicast packets from, for example, the Uplink UPF. That is, in Figure 7, the Multicast Contents Center 40 may be placed between the Uplink UPF (UPF10_3) and the Copy for UPF 20.

[0173] <<6. Fourth Embodiment>> In the first embodiment described above, Copy for UPF20 determines whether an IP packet is a multicast packet based on whether the Destination IP Address of the IP packet is a specific IP address representing a multicast channel, but it is not limited to this.

[0174] For example, this method assumes that all routers (not shown) that may be present in multiple stages between Copy for UPF20 and Copy for UE30 understand a specific IP address representing the Multicast Channel. On the other hand, if a router does not understand a specific IP address, a different method is used to forward the Multicast packet from Copy for UPF20 to Copy for UE30.

[0175] Another possible approach is for Copy for UPF20 to overwrite the Destination IP Address of the multicast packet with the IP Address of Copy for UE30.

[0176] Copy for UPF20 identifies the Multicast Channel from the UE-specific Source IP Address and port number. Copy for UPF20 copies Multicast packets according to the number of corresponding Downlink UPFs and overwrites the Destination IP Address of the copied Multicast packets with the IP Address of Copy for UE30 preceding the Downlink UPF.

[0177] Copy for UE30 identifies the Multicast Channel from the Source IP Address and port number of the received packet. Copy for UE30 copies the Multicast packet according to the number of UEs receiving the packet, overwrites the UE's IP Address with the Destination IP Address of the copied packet, and sends it.

[0178] This allows multicast packets to be routed from Copy for UPF20 to Copy for UE30 even if there is a router between Copy for UPF20 and Copy for UE30 that does not support multicast.

[0179] <<7. Fifth Embodiment>> In the fifth embodiment, we will describe an example where the above-described Multicast is performed as a 3GPP standard. Figure 11 is a sequence diagram showing the processing flow of Multicast according to the fifth embodiment of this disclosure.

[0180] In the example above, the Resource Management Function is responsible for deploying UPF10 for multicast (Uplink UPF and Downlink UPF). In 3GPP, the Resource Management Function is sometimes referred to as MANO (Management And Orchestration) (see TS28.531). Since UPF10 can be considered as a Network Slice, deploying UPF10 for multicast can be expressed as MANO provisioning UPF10 for multicast.

[0181] As shown in Figure 11, the Resource Management Function provides and configures UPF10 for multicast for multiple UPFs (step S101). In the example in Figure 11, in addition to multiple UPFs (Uplink UPF, Downlink UPF), provisioning and configuration for multicast are performed for Copy for UPF20 and Copy for UE30.

[0182] The provisioned UPF10 information is sent from the Resource Management Function to the Core Network / HSS as information about the Network Slice (step S102).

[0183] The Core Network / HSS transmits the Provisioned UPF10 information as NSSAI (Network Slice Selection Assistance Information) to the UE via the Base station (step S103). Traditionally, eMBB or URLLC was transmitted to the UE as NSSAI, but here, the Provisioned UPF10 information is transmitted to the UE as a Network Slice for multicast in the NSSAI. The UE includes a contents provider that uploads multicast packets and a contents consumer that receives multicast packets.

[0184] The UE obtains information on the UPF10 used for the multicast uplink based on NSSAI. Based on the obtained information, the UE performs the procedure to initiate communication (step S104). At this time, the UE specifies the desired Network Slice in the Session request message, which is the procedure for initiating communication. In this embodiment, the UE specifies the multicast UPF10 as the desired Network Slice based on the information obtained based on NSSAI. The SMF (session management function) (see TS23.501) assigns a Network Slice (in this case, UPF10) to the UE according to the UPF10 specified by the UE.

[0185] The UE executes the ATTACH procedure with Core Network / HSS, and an IP address is assigned from SMF (step S105). This IP address information for the UE is then notified from Core Network / HSS to Copy for UE30 (step S106).

[0186] The contents provider UE uploads the multicast packet to the Uplink UPF (step S107). The Uplink UPF sends the multicast packet to Copy for UPF20 (step S108). Copy for UPF20 duplicates the multicast packet and forwards it to Copy for UE30 (step S109).

[0187] Copy for UE30 identifies the multicast channel, whether the UE has obtained an IP address, and the UE's IP address based on the received multicast packet (step S110).

[0188] Copy for UE30 duplicates the multicast packet, adds the UE's IP address, and sends it via Downlink UPF to the UE that is the contents consumer (steps S111, S112).

[0189] In this embodiment, the entity that deploys the UPF10 for multicast may be either MANO or SMF. However, in this embodiment, the Resource Management Function provisions the UPF10, which is a type of Network Slice, and the correspondence between the UE and the UPF10 is also handled by the Resource Management Function. In other words, the Resource Management Function in this embodiment can be said to be a function that performs the roles of both MANO and SMF. Therefore, in this embodiment, the entity that deploys the UPF10 for multicast can be said to be the Resource Management Function, which combines the functions of both MANO and SMF.

[0190] The Resource Management Function, acting like MANO, provisions UPF10. Furthermore, the Resource Management Function provisions Copy for UPF and Copy for UE within or near the UPF10 related to Multicast. Here, provisioning means placing and activating these resources.

[0191] Furthermore, as mentioned above, UPF10 can be considered a Network Slice. Therefore, the Resource Management Function provides information to the Core Network to notify the UE that there is a Network Slice related to Multicast.

[0192] The Core Network notifies the UE of the NSSAI as information for network slice selection. During the process of attaching and establishing a PDU session, the UE may request that its device connect to a network slice capable of performing multicast content uploads, namely UPF10, which is responsible for multicast uplinks. Based on this request, the SMF assigns UPF10 to the UE.

[0193] In the case of 5G, when a terminal attaches, the SMF assigns an IP address to the UE. Copy for UE30 prepares a packet for each UE and assigns the UE's IP address to that packet. In this way, the UE's IP address is used in the processing of Copy for UE30. Therefore, Copy for UE30 obtains the UE's IP address by querying the SMF. In the case of 4G, Copy for UE30 obtains the UE's IP address by a different method (details will be described later).

[0194] As described above, the multicast packets sent by the UE, which is the content provider, are determined by Copy for UPF20 to be multicast packets or not. Copy for UPF20 forwards a copy of the multicast packet to Copy for UE30. Note that Copy for UE30 is located within or near UPF10 (Downlink UPF) which performs multicast downlink.

[0195] At this point, Copy for UE30 may keep the Destination IP Address as the dedicated multicast IP address, or it may change it to Copy for UE30's IP Address. For example, if the router included in the core network supports multicast packets, Copy for UE30 may forward the packets using the Destination IP Address that represents the multicast packets. In this case, the router included in the core network will automatically send the multicast packets to Copy for UE30.

[0196] Copy for UE30 identifies the channel of the incoming multicast packet and determines whether the corresponding UE has obtained an IP address, and what that IP address is at that time. Copy for UE30 copies the packet for each UE, overwrites the UE's IP address in the copied packet, and sends it. Packets that have passed through the Downlink UPF10 are delivered to the UE that is the Contents consumer.

[0197] <<8. Sixth Embodiment>> As mentioned above, UPF10 can be deployed on-premise or in the cloud. In the cloud, the number of UPF10 instances can be easily increased or decreased because computing resources in the cloud are treated as virtual machines.

[0198] On the other hand, in an on-premise environment, UPF10 is located on the same LAN (Local Area Network) as the UE. Therefore, UPF10 has the advantage of reducing communication latency with the Application Server located very close to it. Thus, both deploying UPF10 on-premise and deploying it in the cloud have their own advantages.

[0199] Therefore, in the sixth embodiment, we will explain how to differentiate between providing a multicast service using UPF10 belonging to On-Premise and providing a multicast service using UPF10 belonging to Cloud.

[0200] Figure 12 shows an example of a Multicast service according to the sixth embodiment of this disclosure. Figure 12 shows the case where the Multicast service is provided on UPF10, which belongs to On-Premise.

[0201] As shown in Figure 12, if all UE2 and UE3 receiving multicast packets are connected to the on-premise UPF10_2 (downlink UPF), it is desirable that the UPF10_1 (uplink UPF) providing multicast packets also be located on-premise, just like the downlink UPF.

[0202] This is because it is undesirable from a traffic load and latency perspective for multicast packets to first pass through the Cloud-side UPF10 (Uplink UPF) and then return to the On-premise UPF10 (Downlink UPF).

[0203] Multicast services can be used not only for broadcasting video, but also for providing the same control information to multiple devices and controlling them in a coordinated manner. In controlling multiple devices, latency can be a major problem. Therefore, when multicast packets contain control information, low latency is crucial.

[0204] One advantage of providing a multicast service using UPF10, which belongs to the On-Premise category, is that it has less impact on internet traffic.

[0205] Figure 13 shows an example of a Multicast service according to the sixth embodiment of this disclosure. Figure 13 shows the case where the Multicast service is provided on UPF10 belonging to the Cloud.

[0206] As shown in Figure 13, if all UE2 and UE3 receiving multicast packets are connected to the Cloud's UPF10_4 (Downlink UPF), it is desirable that the UPF10_3 (Uplink UPF) providing multicast packets also be located in the Cloud, just like the Downlink UPF.

[0207] From a latency perspective, providing a multicast service using UPF10, which belongs to the On-Premise category, might result in lower latency. However, UPF10, being an On-Premise service, is typically used for unicast communication services and is preferable for services requiring low latency.

[0208] Figure 14 shows an example of a multicast service. Figure 14 illustrates the case where multicast services are provided in both On-Premise and Cloud-based UPF10 instances.

[0209] As shown in Figure 14, once a multicast packet passes through the on-premise UPF10_1, it then becomes a UDP packet (connectionless communication). UDP packets do not have retransmission capabilities or the ability to signal that a connection has been lost.

[0210] On the other hand, once a multicast packet passes through the Cloud's UPF10_3, it is then carried within a GTP packet (connection communication) containing a UDP packet. GTP packets have retransmission and connection detection capabilities.

[0211] Therefore, when multicast packets travel a long path from the on-premise side to the cloud side, transmitting them as GTP packets maintains better communication quality than transmitting them as UDP packets. In this way, providing multicast services with UPF10 belonging to the cloud helps maintain communication quality.

[0212] Furthermore, as shown in Figure 14, when an Uplink UPF is deployed on-premise, a copy for UPF20 corresponding to the Uplink UPF is also deployed on-premise. The copy for UPF20 in Figure 14 copies multicast packets according to the number of Downlink UPFs and sends them to the Cloud side. Therefore, there is a risk that uplink traffic will increase.

[0213] On the other hand, as shown in Figure 13, when an Uplink UPF is deployed to the Cloud, the copy for UPF20 corresponding to the Uplink UPF is also deployed to the Cloud. The copy for UPF20 in Figure 13 also copies multicast packets according to the number of Downlink UPFs and sends them to the Copy for UE30, but in Figure 13, the Copy for UE30 is also deployed to the Cloud.

[0214] Thus, because the Copy for UE30 that sends multicast packets and the Copy for UE30 that receives them are located on the same Virtual Private Network, the communication path that multicast packets travel through within the Cloud is less likely to be long compared to the case shown in Figure 13.

[0215] Therefore, as shown in Figure 13, providing a multicast service on UPF10 belonging to the Cloud reduces the impact on the communication channel even if traffic increases due to copying and sending multicast packets.

[0216] In this way, by providing the multicast service using UPF10, which belongs to the On-Premise category, the latency of the multicast service can be reduced.

[0217] Furthermore, by providing a multicast service using UPF10, which belongs to the Cloud, it is possible to suppress the increase in traffic on the ISP's (Internet Service Provider) communication channels. In addition, it is possible to avoid vulnerable UDP packets traveling through long communication paths.

[0218] Furthermore, depending on the requirements for the Multicast service (e.g., low latency), the Resource Management Function described above will deploy the UPF10 used for Multicast either on-premise or in the cloud.

[0219] <<9. Seventh Embodiment>> In the embodiments described above, the multicast service is provided within a single private network, but this is not limited to that. A single private network is, for example, a network consisting of a factory, hospital, office, or home. It is also conceivable to provide multicast packets to multiple private networks. The seventh embodiment describes the case in which multicast packets are provided to multiple private networks.

[0220] For example, in the first embodiment described above, copy for UPF20 forwarded multicast packets to the Downlink UPF using information that associated multicast channels with Downlink UPFs, as shown in Table 2 above.

[0221] However, the information shown in Table 2 does not support Downlink UPF for multiple Private Networks, and copy for UPF20 cannot forward multicast packets to Downlink UPF for multiple Private Networks using only the information shown in Table 2.

[0222] As mentioned above, Multicast has multiple channels (programs, sessions). Therefore, managing which Private Network to forward each channel to becomes a complex procedure and is difficult to implement in systems that require simple and low-cost operation, such as Private Networks.

[0223] When providing a multicast service within a single Private Network, as in the first embodiment, as described above, the Copy for UPF20 located after the Uplink UPF should determine, for each channel, which UPF to copy and forward packets to. However, if the Copy for UPF20 is required to determine forwarding to UPF10s in other Private Networks, not just within a single Private Network, the configuration shown in Table 2 becomes complex.

[0224] Therefore, in the seventh embodiment of this disclosure, a dedicated UPF10 for forwarding to other private networks is placed within the private network.

[0225] Figure 15 is a diagram illustrating a multicast according to the seventh embodiment of this disclosure. As shown in Figure 15, the multicast service according to this embodiment is provided on Private Cellular Network A and Private Cellular Network B. More specifically, multicast packets uploaded on Private Cellular Network A are sent to the UEs of Private Cellular Network A and Private Cellular Network B.

[0226] Note that the configurations of Private Cellular Network A and Private Cellular Network B are the same as those in Figure 7, except that Private Cellular Network B has a Multicast Gateway (GW) 50. In Figure 15, the Multicast GW 50 is located in Private Cellular Network B, but the Multicast GW 50 can also be located in Private Cellular Network A in the same way.

[0227] The Multicast GW50 is a gateway for receiving multicast packets on the Private Network. Private Cellular Network B notifies Private Network A, the source of the packets, of the IP address of the Multicast GW50.

[0228] Copy for UPF20A, located near the Uplink UPF (UPF10_3A in Figure 15) of Private Cellular Network A, holds information such as that shown in Table 5. Table 5 shows the correspondence between the Multicast Channel ID and the Downlink UPF ID being used, but differs from Table 2 in that the IP address of Multicast Gateway (GW) 50 is included as the Downlink UPF ID being used.

[0229] [Table 5]

[0230] The example in Table 5 shows that a multicast packet with Multicast Channel ID "1" is forwarded to UPF10 with Downlink UPF ID "4". Here, UPF10 with Downlink UPF ID "4" is, for example, UPF10_4A on Private Cellular Network A.

[0231] Furthermore, the Downlink UPF IDs corresponding to a Multicast packet with Multicast Channel ID "2" are "4" and "Multicast Gateway". In this case, Copy for UPF20A forwards the Multicast packet to UPF10_4A and to the Multicast Gateway (GW) 50 of Private Cellular Network B. Copy for UPF20A forwards the Multicast packet to Multicast Gateway (GW) 50 using the IP address of Multicast GW 50, which was notified in advance. Table 5 shows the case where the IP address of Multicast GW 50 is, for example, "100.10.1.5".

[0232] The Downlink UPF ID corresponding to a multicast packet with a Multicast Channel ID of "3" is "Multicast Gateway". In this case, Copy for UPF20A forwards the multicast packet to Multicast Gateway (GW) 50 on Private Cellular Network B.

[0233] In this way, a Multicast Gateway (GW) 50 that receives multicast packets is provided in Private Cellular Network B. This allows Copy for UPF20A to forward multicast packets to Private Cellular Network B without using information about UPF10 within Private Cellular Network B.

[0234] Furthermore, the Multicast Gateway (GW) 50 forwards the received multicast packets to Copy for UE30B, for example, in the same way as Copy for UPF20. This allows the Private Cellular Network B to also send multicast packets to UE2B and UE3B via Downlink UPF (UPF10_4B in Figure 15).

[0235] In this way, by using Copy for UPF20A on Private Cellular Network A to identify multicast packets destined for Private Cellular Network B, the number of locations where this identification is performed can be limited to a minimum, for example. Furthermore, a multicast gateway (GW) 50 is provided on Private Cellular Network B to receive multicast packets. This allows Copy for UPF20A to forward multicast packets to Private Cellular Network B without having to copy them to each other UPF10B on Private Cellular Network B. Therefore, multicast services can be provided across multiple Private Cellular Networks in a simple manner. This, in turn, reduces the cost of providing multicast services across multiple Private Cellular Networks.

[0236] For example, one possible use case is to simultaneously control a very large number of IoT devices included in a private cellular network deployed worldwide using the same command. To realize such use cases, it is considered effective to provide a multicast service using the method according to this embodiment.

[0237] <<10. Eighth Embodiment>> As described above, in each embodiment of this disclosure, Copy for UE30 uses the UE's IP address to convert multicast packets into unicast packets. Thus, the technology of this disclosure uses the UE's IP address in Copy for UE30, which is provided in front of the Downlink UPF.

[0238] Copy for UE30 identifies UEs belonging to the Downlink UPF that desire the Multicast Service, and then identifies the IP addresses of UEs that have obtained IP addresses. Furthermore, Copy for UE30 identifies which UEs desire to receive the Multicast Service for each Multicast Channel. In a private network, it is desirable to implement these processes by Copy for UE30 in a low-cost and simple manner.

[0239] On a typical internet connection, the IP address of the UE (User Environment) can be obtained using a method called UDP broadcast, which utilizes the response from the terminal. However, in a cellular network, packets are delivered to the UE via a GTP tunnel, so the UE's IP address cannot be obtained in the same way as on the internet.

[0240] In the Cellular Network, the IP address assigned to the UE via the Attach Procedure is stored in the Core Network's subscriber file, but this information may not be accessible from the outside.

[0241] Therefore, in order to perform multicast using the technology disclosed herein, a mechanism is required to more reliably obtain the UE's IP address. In particular, in the technology disclosed herein, Copy for UE30 copies the multicast packet for the UE and then overwrites the UE's IP address with the multicast IP address. Therefore, a mechanism is required to more reliably obtain the UE's IP address.

[0242] Therefore, in the eighth embodiment, a method for obtaining the IP address of the UE will be described. Figure 16 is a sequence diagram showing the multicast flow according to the eighth embodiment of this disclosure.

[0243] As shown in Figure 16, the UE, which is the content consumer, notifies the Resource Management Function of the Multicast Channel it wishes to view (step S201). The Resource Management Function notifies the Uplink UPF of which Downlink UPF should copy the Multicast packets to for each Multicast Channel (step S202). The Resource Management Function also notifies the Downlink UPF of the group of UEs that wish to view each Multicast Channel (step S203).

[0244] Copy for UE30 requests the SMF / HSS to obtain the IP address using the UE's ID (step S204). SMF / HSS obtains the UE's IP address using the Attach Procedure (step S205). SMF / HSS notifies Copy for UE30 of the obtained UE's IP address (step S206).

[0245] When a multicast packet is uploaded from the contents provider UE to the Uplink UPF (step S207), the Uplink UPF sends the multicast packet to Copy for UPF20 (step S208). Copy for UPF20 copies and forwards the multicast packet to the UPF10 corresponding to the multicast channel of the multicast packet (Target's UPF10) (step S209). More specifically, Copy for UPF20 forwards the multicast packet to Target's UPF10 by forwarding it to Copy for UE30 located within or near Target's UPF10.

[0246] Copy for UE30 identifies the Multicast Channel, the UE that is the contents consumer, whether or not the IP address of the identified UE has been obtained, and the IP address of the UE based on the received Multicast packet (step S210). Based on the processing in step S210, Copy for UE30 copies the Multicast packet for the UE that will send the Multicast packet (Target UE), assigns an IP address to it, and forwards it to the Downlink UPF (step S211). As a result, the packet is sent to the UE that is the contents consumer via the Downlink UPF (step S212).

[0247] Here, we will explain the process in step S210 in more detail.

[0248] Step 1: Identifying the Multicast Channel Copy for UE30 identifies which multicast channel an incoming multicast packet belongs to. Generally, a UPF10 that can view a multicast channel is fixed (see Table 2), but multiple multicast channels may be assigned to a single UPF10. Therefore, Copy for UE30 identifies which multicast channel a multicast packet belongs to by using the multicast IP address, which indicates the multicast channel located at the destination IP address.

[0249] Step 2: Identifying the Unified End-User (UE) Copy for UE30 retrieves the ID (IMSI or SUPI) of the UE that wishes to view the identified Multicast Channel. Unlike IGMP, an internet technology, Copy for UE30 retrieves this information from semi-static information registered before the UE obtains its IP address. For example, Copy for UE30 retrieves information on which Multicast Channel each IMSI (SUPI) wishes to view.

[0250] For example, by defining an upper limit (e.g., 10) on the number of UEs that can view one Multicast Channel associated with one UPF10, the upper limit (e.g., 10) on packet duplication and copying is determined. Therefore, the process of identifying UEs using Copy for UE30 is considered easy to implement.

[0251] Step 3: Whether or not to obtain the UE's IP address, and obtaining the UE's IP address. Copy for UE30 checks whether any UEs identified as wanting to view the Multicast Channel from among those that are known to be associated with Downlink UPF have obtained an IP address.

[0252] For example, Copy for UE30 can determine if an IP address has been obtained by referring to a table that shows how many of the 10 UEs identified in Step 2 have already obtained an IP address.

[0253] For UEs that have already obtained an IP address, Copy for UE30 duplicates the packet and then overwrites it with the UE's IP address as the destination IP address. For this process to work, it's crucial for Copy for UE30 to know whether or not the UE has already obtained an IP address. Knowing whether each Copy for UE30 has obtained an IP address allows for faster processing.

[0254] Then, Copy for UE30 retrieves the IP address of the assigned UE in order to use the IP address.

[0255] Having obtained the UE's IP address by executing Steps 1 to 3, Copy for UE30 then performs the process shown in step S211 of Figure 16. More specifically, Copy for UE30 prepares copied packets according to the number of UEs that have IP addresses, overwrites the IP address of each UE, and sends them.

[0256] The following explains how to obtain the UE's IP address as described in Step 3.

[0257] In 5G, Copy for UE30 uses the 5G API to obtain the UE's IP address from the SMF. In this way, Copy for UE30 can use the SMF API to obtain the IP address corresponding to the UE's ID for the Multicast Service.

[0258] On the one hand, in the case of 4G, Copy for UE30 obtains the IP address of the UE by sniffing the packets during the Attach Procedure. Here, using Figure 17, an example of the Attach Procedure performed between the UE, which is the contents consumer, and the Core Network / HSS will be described. Figure 17 is a sequence diagram showing the flow of the Attach Procedure.

[0259] As shown in Figure 17, first, the UE sends an Attach ReqUEst to the Core Network / HSS (step S301). The Core Network / HSS sends an Identity reqUEst to the UE (step S302).

[0260] Subsequently, the UE sends an Identity Response to the Core Network / HSS (step S303). The Identity Response includes information regarding the IMSI (an example of the identification information of the terminal device) and the S1AP ID (an example of the communication session ID).

[0261] The Core Network / HSS sends an Attach accept to the UE (step S304). The Attach accept includes information regarding the IP Address and the S1AP ID.

[0262] Copy for UE30 sniffs the packets during the Attach Procedure shown in Figure 17. For example, Copy for UE30 uses the information regarding the IMSI and the S1AP ID (an example of the first corresponding information) exchanged in step S303 and the information regarding the IP Address and the S1AP ID (an example of the second corresponding information) exchanged in step S304 to associate the IMSI with the IP Address. Thereby, Copy for UE30 obtains the IP address for each UE.

[0263] Note that the Attach Procedure is performed between steps S303 and S304, but its explanation is omitted here. Also, Core Network / HSS may perform the Attach Procedure with other UEs. In this case, Copy for UE30 can recognize whether it is the same UE procedure by checking the ID of S1AP.

[0264] Next, we will explain the details of using the Attach Procedure with Copy for UE30 to access an IP address.

[0265] [Step 1] Copy for UE30 captures packets that have an S1AP layer on top of the SCTP layer. Here, Figure 18 shows the protocol stack of S1AP. Figure 18 is a diagram showing an example of the protocol stack between the UE and Core Network / HSS. As shown in Figure 18, S1AP is a protocol carried over the SCTP protocol on IP, and the UE's IMSI and IP address are carried as information in S1AP.

[0266] [Step 2] Copy for UE30 examines the S1AP messages line by line and extracts information using three keywords as clues: "ENB-UE-S1AP-ID", "IMSI", and "PDN IPv4".

[0267] [Step 3] Copy for UE30 maintains the following two lists, with NumberMaxUE representing the upper limit of the number of UEs that may perform the attach procedure simultaneously. sList_State_S1ID[NumberMaxUE] sList_State_IMSI[NumberMaxUE]

[0268] When Copy for UE30 receives a packet containing IMSI information, it stores the IMSI information in sList_State_IMSI[e.g., index = 4] and the S1ID at that time in sList_State_S1ID[e.g., index = 4]. Before storing the S1ID, Copy for UE30 checks if the same S1ID already exists in sList_State_S1ID[] and deletes it if it does. This allows Copy for UE30 to eliminate ghost data in case of errors.

[0269] Next, when Copy for UE30 receives a packet containing IP address information, it checks if the same S1ID exists in sList_State_S1ID[]. If a match is found, Copy for UE30 retrieves the IP address from the corresponding sList_State_IMSI[]. At that time, Copy for UE30 initializes the contents of the retrieved sList_State_S1ID[e.g., index = 4] and sList_State_IMSI[e.g., index = 4].

[0270] This allows Copy for UE30 to associate the IMSI with the IP address, and to obtain the IP address for each UE.

[0271] In the technology disclosed herein, Copy for UE30 copies multicast packets only after determining whether the UE has obtained an IP address. Therefore, unnecessary copying of packets by Copy for UE30 can be suppressed, and the processing load on Copy for UE30 can be reduced.

[0272] Furthermore, as mentioned above, by setting an upper limit on the number of UEs belonging to a single Multicast Channel and a single UPF10, it is possible to set an upper limit on the number of packets copied by Copy for UE30. This reduces the processing load of Copy for UE30 and lowers the probability of congestion.

[0273] Copy for UE30 can begin forwarding packets as soon as it obtains an IP address. In other words, multicast can start as soon as the UE obtains an IP address. Therefore, for example, when controlling multiple UEs with multicast, control of the UEs can start immediately after powering on.

[0274] <<11. Application Examples>> The Multicast in each of the embodiments described above can be applied to various use cases. Here, we will explain using the case where the Private Network described in the first embodiment is used for film shooting as an example.

[0275] Figure 19 is a diagram illustrating an example of the application of the technology of this disclosure. As shown in Figure 19, when a Private Network is used for filming a movie, the captured video is uploaded to the Private Network. The uploaded video is multicasted to monitors connected to the Private Network, allowing the film director and staff to view the captured video.

[0276] In this case, for example, the camera that captures the footage for the film corresponds to the UE, which is the Source Contents. The camera uploads the captured video to the Uplink UPF. By placing the Uplink UPF, which processes the video upload, on the Private Network in this way, the captured video can be uploaded with high priority.

[0277] Also, the uploaded video is copied by Copy for UPF and transferred to the Downlink UPF via Copy for UE. In Copy for UE, the uploaded video is copied and transferred for each UE (e.g., monitor) that is the contents consumer.

[0278] At this time, for example, assume that the monitor watched by the movie director is set to have a high priority (High Priority), and the monitors of the staff other than the movie director are set to have a low priority (Low Priority). This priority setting is performed, for example, by associating the monitor watched by the movie director with one Downlink UPF, and grouping the multiple monitors watched by the other staff and associating them with one Downlink UPF.

[0279] In this way, by setting the priority according to the UE (here, the monitor), it is possible to preferentially transmit Multicast packets (e.g., the captured video) to important UEs such as the monitor watched by the movie director.

[0280] <<12. Summary>> The above embodiments are merely examples, and various modifications and applications are possible. Also, the above embodiments can be appropriately combined as long as the processing contents do not conflict.

[0281] Also, store the program for executing the above operations in a computer-readable recording medium such as an optical disk, semiconductor memory, magnetic tape, flexible disk, etc. and distribute it. Then, for example, install the program in a computer and configure a control device by executing the above processing. At this time, the control device may be an external device (e.g., a personal computer) of Copy for UPF20 and Copy for UE30. Also, the control device may be an internal device (e.g., control units 23, 33) of Copy for UPF20 and Copy for UE30.

[0282] Alternatively, the above program may be stored on a disk drive provided by a server device on a network such as the Internet, and made available for download to a computer. Furthermore, the above functions may be implemented through the cooperation of an OS (Operating System) and application software. In this case, the parts other than the OS may be stored on a medium and distributed, or the parts other than the OS may be stored on a server device and made available for download to a computer.

[0283] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by known methods. In addition, the processing procedures, specific names, and various data and parameters shown in the above document and drawings can be changed at will unless otherwise specified. For example, the various information shown in each figure is not limited to the information shown.

[0284] Furthermore, the components of each illustrated device are functionally conceptual and do not necessarily need to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions.

[0285] Furthermore, the above-described embodiments can be combined as appropriate in areas where the processing content is not contradictory. Also, the steps shown in the flowcharts and sequence diagrams of the above-described embodiments can be changed in order as appropriate.

[0286] Furthermore, for example, this embodiment can also be implemented as any configuration that makes up a device or system, such as a processor as a system LSI (Large Scale Integration), a module using multiple processors, a unit using multiple modules, or a set with additional functions added to a unit (i.e., a configuration of a part of a device).

[0287] In this embodiment, a system refers to a collection of multiple components (devices, modules (parts), etc.), regardless of whether all components are located in the same enclosure. Therefore, multiple devices housed in separate enclosures and connected via a network, and a single device containing multiple modules within a single enclosure, are both considered systems.

[0288] Furthermore, for example, this embodiment can adopt a cloud computing configuration in which a single function is shared and processed collaboratively by multiple devices via a network.

[0289] Although embodiments of this disclosure have been described above, the technical scope of this disclosure is not limited to the embodiments described above, and various modifications are possible without departing from the gist of this disclosure. Furthermore, components from different embodiments and modifications may be combined as appropriate.

[0290] Furthermore, the effects described in each embodiment of this specification are merely illustrative and not limiting, and other effects may also occur.

[0291] Furthermore, this technology can also be configured as follows. (1) A relay device provided in response to one or more first UPFs (User plane functions), A control unit that converts multicast data into unicast data destined for one or more terminal devices, A transmission unit that transmits the unicast data to the multiple terminal devices, A relay device equipped with the following features. (2) The relay device according to (1), wherein the first UPF is configured as a UPF that performs downlink transmission of the multicast data. (3) The control unit receives multicast data from a second UPF that transmits multicast data uplink, as described in (1) or (2). (4) The relay device according to (3), wherein the first UPF is set to be a different UPF from the second UPF. (5) The relay device according to (3) or (4), wherein the control unit receives the multicast data from the second UPF via a second relay device that relays the multicast data. (6) The relay device described in (5), wherein the second relay device relays the multicast data to the first UPF in an order corresponding to the priority of the terminal devices corresponding to the first UPF. (7) The relay device according to any one of (1) to (6), wherein the control unit replicates the multicast data in an order corresponding to the priority of the terminal devices and converts it into unicast data. (8) The relay device according to any one of (1) to (6), wherein the control unit generates the unicast data to be transmitted to a number of terminal devices according to priority. (9) The terminal device receives selection information for selecting the first UPF or the second UPF, The aforementioned selection information is transmitted along with the network slice information. A relay device as described in any one of (3) to (6). (10) The control unit, The terminal device that wishes to receive the multicast data obtains address information relating to the IP address acquired by the terminal device, The unicast data is generated based on the address information. A relay device as described in any one of (1) to (9). (11) The relay device according to (10), wherein the control unit generates the unicast data by converting the destination of the multicast data to the IP address acquired by the terminal device. (12) The control unit obtains the address information from the SMF (Session Management Function), as described in (10) or (11). (13) The control unit, From the first attachment information transmitted by the terminal device when it attaches to the network, a first correspondence information is obtained that associates the identification information of the terminal device with the communication session ID. From the second attachment information received when the terminal device attaches to the network, a second correspondence information is obtained that associates the IP address assigned to the terminal device with the session ID. If the session ID of the first correspondence information and the session ID of the second correspondence information are the same, the identification information and IP address of the terminal device corresponding to the session ID are associated with each of them. The relay device described in (10) or (11). (14) A method for relaying data using relay devices provided in response to one or more first UPFs (User plane functions), Converting multicast data into unicast data destined for one or more terminal devices, The unicast data is transmitted to the multiple terminal devices, A method that includes this. [Explanation of symbols]

[0292] 10 UPF 20 Copy for UPF 21, 31 Communications Department 22, 32 Storage section 23, 33 Control Unit 30 Copy for UE

Claims

1. A relay device provided in response to one or more first UPFs (User Plane Functions), A control unit that converts multicast data acquired from a second UPF different from the first UPF into unicast data destined for one or more terminal devices located within the private area of ​​a private network, A transmission unit that transmits the unicast data to the first UPF, Equipped with, The first UPF transmits the unicast data to the one or more terminal devices. A relay device.

2. The relay device according to claim 1, wherein the first UPF is configured as a UPF that performs downlink transmission of the multicast data.

3. The relay device according to claim 2, wherein the control unit receives the multicast data from the second UPF which performs uplink transmission of multicast data.

4. The relay device according to claim 3, wherein the control unit receives the multicast data from the second UPF via a second relay device that relays the multicast data.

5. The relay device according to claim 4, wherein the second relay device relays the multicast data to the first UPF in an order corresponding to the priority of the terminal devices corresponding to the first UPF.

6. The relay device according to claim 1, wherein the control unit duplicates the multicast data in an order corresponding to the priority of the terminal devices and converts it into unicast data.

7. The relay device according to claim 1, wherein the control unit generates the unicast data to be transmitted to a number of terminal devices according to priority.

8. The terminal device receives selection information for selecting the first UPF or the second UPF. The aforementioned selection information is transmitted along with the network slice information. The relay device according to claim 3.

9. The control unit, The terminal device that wishes to receive the multicast data obtains address information relating to the IP address acquired by the terminal device, The unicast data is generated based on the address information. The relay device according to claim 1.

10. The relay device according to claim 9, wherein the control unit generates the unicast data by converting the destination of the multicast data to the IP address acquired by the terminal device.

11. The relay device according to claim 9, wherein the control unit obtains the address information from the SMF (Session Management Function).

12. The control unit, From the first attachment information transmitted when the terminal device attaches to the network, a first correspondence information is obtained that associates the identification information of the terminal device with the communication session ID. From the second attachment information received when the terminal device attaches to the network, a second correspondence information is obtained that associates the IP address assigned to the terminal device with the session ID. If the session ID of the first correspondence information and the session ID of the second correspondence information are the same, the identification information and IP address of the terminal device corresponding to the session ID are associated with each of them. The relay device according to claim 9.

13. A method for relaying data using relay devices provided in response to one or more first UPFs (User Plane Functions), Convert multicast data obtained from a second UPF, which is different from the first UPF, into unicast data destined for one or more terminal devices within a limited area. The unicast data is transmitted to the first UPF, Includes, The first UPF transmits the unicast data to the one or more terminal devices. method.

Images