WO2012026461A1 - 移動通信システム、移動局装置、ホーム基地局装置及び通信方法 - Google Patents

移動通信システム、移動局装置、ホーム基地局装置及び通信方法 Download PDF

Info

Publication number
WO2012026461A1
WO2012026461A1 PCT/JP2011/068964 JP2011068964W WO2012026461A1 WO 2012026461 A1 WO2012026461 A1 WO 2012026461A1 JP 2011068964 W JP2011068964 W JP 2011068964W WO 2012026461 A1 WO2012026461 A1 WO 2012026461A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
request
participation request
bearer
home network
Prior art date
Application number
PCT/JP2011/068964
Other languages
English (en)
French (fr)
Inventor
真史 新本
Original Assignee
シャープ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by シャープ株式会社 filed Critical シャープ株式会社
Publication of WO2012026461A1 publication Critical patent/WO2012026461A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/186—Processing of subscriber group data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast

Definitions

  • the present invention relates to a mobile communication system in which a home network having a home base station device to which a mobile station device is connected and a core network to which a location management device and an access control device are connected are connected via an external network. .
  • the standardization organization 3GPP The 3rd Generation Generation Partnership Project
  • EPS Evolved Packet System
  • Non-Patent Document 1 the next generation mobile communication system.
  • a HeNB Home eNodeB: home base station
  • a small base station installed in a house or the like has been studied.
  • the HeNB constructs a small-scale radio cell called a femto cell and accommodates a UE (User : Equipment: mobile terminal device) using the same radio access technology as that of a normal base station. And it can connect to the core network of a mobile communication system via a broadband line, and can relay the communication data of the accommodated UE.
  • a UE User : Equipment: mobile terminal device
  • Non-Patent Document 2 discloses an architecture candidate for realizing local IP access in HeNB.
  • the local IP access is a function that provides the UE with direct connectivity to a network such as a home IP network (hereinafter referred to as “home network”) to which the HeNB is directly connected. It is possible to communicate with other information terminals (for example, a digital video recorder, a printer, etc.) connected to the home network without going through the core network of the system.
  • home network a home IP network
  • the MBMS Multimedia Broadcast / Multicast Service
  • a core network for example, see Non-Patent Document 3
  • BM-SC Broadcast-Multicast Service Centre
  • MBMS-GW Multimedia Broadcast / Multicast Service-Gateway
  • UPnP Universal Plug
  • LAN local area network
  • a home network for example, a “print service” provided by a printer device.
  • service discovery protocol using multicast such as (and Play) (for example, see Non-Patent Document 4).
  • Non-Patent Document 2 discloses the use of a multicast service using local IP access. Although there is a description as a required condition, no specific means for realizing it has been described, and it could not be realized.
  • 3GPP TS23.401 General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access 3GPP TR 23.829 Local IP Access and Selected IP IP Traffic Offload 3GPP TS 23.246 Multimedia Broadcast / Multicast Service; Architecture and functional description UPnP Device Architecture 1.1
  • GPRS General Packet Radio Service
  • Non-Patent Document 2 In the architecture candidate that realizes local IP access disclosed in Non-Patent Document 2, UEs that have been shipped to the market before the local IP access specifications are formulated are supported, and a requirement is set that the UE can be implemented without any changes. Has been.
  • the UE does not know whether the communication data is transferred via the core network or is transferred using local IP access, and is based on flow identification information called TFT (Traffic Flow Template) according to the conventional specification.
  • TFT Traffic Flow Template
  • an IGMP (Internet Group Management Protocol) Join message is used for communication using IPv4
  • an MLD is used for communication using IPv6.
  • the message is transmitted to the same address (“FF02 :: 16” for IPv6, “224.0.0.22” for IPv4) regardless of which multicast group it joins.
  • the TFT that identifies the “flow” by destination address, protocol number, port number, etc., selects whether or not the participation request is a request for a multicast service using local IP access, and selects a bearer. It cannot be sent.
  • the UE transmits to the bearer connected to the core network, and the transmitted participation request message can only be received by an access control device called SGW (Serving GW) in the core network which is the default router of the UE.
  • SGW Serving GW
  • the multicast group participation request transmitted by the UE is a local IP access participation request by a device in the core network such as SGW or a location management device such as MME (Mobility Management Entity) It is possible to determine whether the message is a participation request message for performing the procedure for delivering the multicast communication requested by the UE.
  • a device in the core network such as SGW or a location management device such as MME (Mobility Management Entity) It is possible to determine whether the message is a participation request message for performing the procedure for delivering the multicast communication requested by the UE.
  • MME Mobility Management Entity
  • the participation request of the UE is determined by the HeNB installed in the home network as a participation request for local IP access or a participation request message for the MBMS service. It is necessary to perform a procedure for receiving multicast data.
  • the HeNB has no such determination means, and furthermore, there has been no means for receiving multicast data for local IP access based on this determination and no means for receiving multicast data for the MBMS service.
  • the UE cannot enjoy the multicast service provided in the home network and cannot use the above-described functions such as UPnP.
  • the present invention has been made in view of such circumstances, and an object of the present invention is to make it possible for a mobile station apparatus connected to a home base station to detect an equivalent means without detecting whether it is a multicast group for local IP access.
  • the home base station determines whether the multicast group requested by the mobile station apparatus to participate is provided in the home network or the core network, and determines a suitable multicast session according to the determination. It is to provide a mobile communication system or the like that can be established.
  • the mobile communication system according to the present invention has the following features.
  • the mobile communication system of the present invention is a mobile network in which a home network having a home base station device to which a mobile station device is connected and a core network to which a location management device and an access control device are connected are connected via an external network.
  • the home base station device Multicast participation request receiving means for receiving a multicast participation request transmitted from the mobile station device; Multicast participation request determining means for determining whether or not the multicast participation request is a multicast participation request addressed to a home network; When the multicast participation request determination means determines that the multicast participation request is addressed to a home network, a bearer change that transmits a bearer change request for changing a bearer to which multicast data is transmitted and received is transmitted to the mobile station device.
  • a request sending means It is characterized by providing.
  • the home base station device A multicast address storing means for storing an address to be a multicast participation request addressed to the home network;
  • the multicast participation request determination unit determines that the multicast address included in the multicast participation request is a multicast request addressed to a home network when the multicast address storage unit stores the multicast address.
  • the multicast participation request determining means determines that the multicast participation request is not addressed to a home network
  • the multicast participation request is transmitted to the core network.
  • the home base station device establishes with the mobile station device a first bearer that communicates with a home network and a second bearer that communicates with a core network
  • the multicast participation request receiving means receives the multicast participation request from the mobile station device via the second bearer.
  • the mobile station apparatus connected to the mobile communication system of the present invention changes a bearer that transmits and receives multicast data, and performs home via the home base station apparatus.
  • a multicast session is established in the network.
  • the mobile station device connected to the mobile communication system of the present invention, Establishing a first bearer communicating with the home network and a second bearer communicating with the core network; A multicast participation request addressed to the home network is transmitted via the second bearer.
  • the home base station apparatus of the present invention A home base connected to a mobile communication system in which a home network having a home base station device to which a mobile station device is connected and a core network to which a location management device and an access control device are connected are connected via an external network
  • a station device Multicast participation request receiving means for receiving a multicast participation request from the mobile station device; Multicast participation request determination means for determining whether the multicast participation request is a multicast request addressed to a home network;
  • a bearer change request for transmitting a bearer change request for changing a bearer to which multicast data is transmitted and received to the mobile station apparatus when the multicast request is determined to be addressed to a home network by the multicast participation request determination unit.
  • the communication method of the present invention includes: A communication method in a mobile communication system in which a home network having a home base station device to which a mobile station device is connected and a core network to which a location management device and an access control device are connected are connected via an external network.
  • the home base station device is Receiving a multicast participation request transmitted from the mobile station device; Determining whether the received multicast participation request is a multicast participation request addressed to a home network; When it is determined that the multicast participation request is addressed to a home network, a bearer change request for changing a bearer to which multicast data is transmitted and received is transmitted to the mobile station device.
  • a suitable multicast session establishment procedure can be selected while maintaining compatibility with existing systems, and the UE can also use a multicast service provided in a local IP access environment.
  • FIG. 1 is a diagram for explaining an outline of a mobile communication system 1 in the present embodiment.
  • the mobile communication system 1 includes a core network 3, a home network 5, and a broadband access network 7, and the core network 3 and the home network 5 are interconnected via the broadband access network 7.
  • the broadband access network 7 has been.
  • the broadband access network 7 is a wired access network that realizes broadband communication, and is constructed by, for example, ADSL (Asymmetric Digital Subscriber Line) or an optical fiber.
  • ADSL Asymmetric Digital Subscriber Line
  • optical fiber an optical fiber.
  • the present invention is not limited to this, and a wireless access network such as WiMAX (Worldwide Interoperability for Microwave Access) may be used.
  • the core network 3 is a mobile communication network operated by a mobile communication operator, and an MME 10, a GW 20, an SGW 30, a PGW (Packet data network GW) 40, and an MBMS-GW 50 are arranged.
  • the MME 10 is an entity that performs signaling, and is a location management device that leads the location management of the mobile station device (UE 90) and the establishment procedure of the EPS bearer.
  • the EPS bearer is a logical path for transferring a user IP packet established between the PGW 40 and the UE 90 for each UE.
  • An EPS bearer can be set with a specific QoS level and is associated with a TFT.
  • a TFT is defined by a set of filter information for identifying a flow as communication data, and a destination address and a port number can be designated for each filter information. Therefore, the traffic flow of a specific application and the flow with a specific communication partner can be identified by the TFT.
  • the GW 20 functions as a gateway between the HeNB 80 installed in the home network 5 and a device in the core network. Communication between the MME 10 and the HeNB 80, between the SGW 30 and the HeNB 80, and between the MBMS-GW 50 and the HeNB 80 is performed via the GW 20.
  • the SGW 30 is an access control device that transfers packets between the PGW 40 and the HeNB 80. Note that the PGW 40 and the SGW 30 may be physically configured by the same node.
  • the PGW 40 is connected to an external PDN (Packet Data Network: packet communication network) such as the Internet, functions as a gateway that connects the core network 3 and those PDNs, and transfers the communication data of the UE 90 to the SGW 30. is there.
  • PDN Packet Data Network: packet communication network
  • the MBMS-GW 50 is a device that transfers MBMS multicast data to the HeNB 80, is connected to the HeNB 80 via the GW 20, and is also connected to the MME 10.
  • the home network 5 is a home network in a home, a corporate network such as a company, and the like, and includes a home GW 60, an information terminal 70, a HeNB 80, and a UE 90. Further, the home network 5 is connected to the broadband access network 7.
  • the home GW 60 is a gateway device between the home network and the broadband access network, and is a conventional broadband router device such as a router with a built-in ADSL modem.
  • the information terminal 70 is a device capable of IP communication connected to the home network 5, and is, for example, a printer, a digital video recorder, a PC connected to the home, or the like. It also supports UPnP and announces a service to be provided (for example, “print service”) in the home network. Normally, a plurality of devices can be connected. However, in the present embodiment, for convenience of explanation, one information terminal 70 will be described as an example.
  • the HeNB 80 accommodates the UE as a base station provided by the core network operator while being installed in the home network. Typically, this is a 3GPP LTE (Long Term Evolution) base station that forms a femto cell.
  • 3GPP LTE Long Term Evolution
  • the UE 90 is a mobile communication terminal connected to the HeNB and is connected with a 3GPP LTE communication interface or the like.
  • the home GW 60 is configured in the same manner as a conventional broadband router device, detailed description thereof is omitted.
  • FIG. 2 shows a configuration of the MME 10 in the present embodiment.
  • a transmission / reception unit 110 and a storage unit 130 are connected to the control unit 100 via a bus.
  • the control unit 100 is a functional unit for controlling the MME 10.
  • the control unit 100 implements various processes by reading and executing various programs stored in the storage unit 130.
  • the transmission / reception unit 110 is a functional unit that is wired to a router or a switch and transmits and receives packets.
  • transmission / reception is performed by Ethernet (registered trademark) or the like generally used as a network connection method.
  • the storage unit 130 is a functional unit that stores programs, data, and the like necessary for various operations of the MME 10. Further, the storage unit 130 stores a subscription DB (database) 132 and an EPS bearer context 134.
  • FIG. 3 is a diagram illustrating an example of the subscription DB 132, which includes a UE identifier (for example, “UE1”), a CSG identifier (for example, “CSG1”), and a right to use local IP access (for example, “permitted”). It is a database that is stored in association with each other.
  • the CSG (Closed Subscriber Group) identifier is an identifier for uniquely identifying the HeNB 80, and the subscription DB 132 determines which HeNB 80 can use the local IP access.
  • FIG. 4 is a diagram showing an example of the EPS bearer context 136.
  • a UE identifier eg “UE1”
  • bearer ID eg “bearer 1”
  • UL TFT UplinkTFTTFT
  • all UL TFT
  • LIPA Local
  • the bearer ID is an identifier for identifying an EPS bearer, and the LIPA setting indicates whether or not each EPS bearer uses local IP access.
  • the UL TFT identifies a flow (uplink flow) transmitted from the UE 90.
  • the bearer established by the UE 90 can be grasped by the EPS bearer context 134, and the flow flowing through each bearer is managed. Furthermore, it manages whether to use local IP access for each bearer. For example, as shown in FIG. 4B, UE1 has established bearer 2 capable of local IP access, and designates “Destination: 2001: 2: 3: 4 :: / 64” to UL TFT. The flow addressed to the device connected to the home network is managed by communicating using the bearer 2.
  • the control unit 300 is a functional unit for controlling the SGW 30.
  • the control unit 300 implements processing by reading and executing various programs stored in the storage unit 330.
  • the first transmission / reception unit 310 and the second transmission / reception unit are functional units that are connected to other devices and perform transmission / reception of data.
  • transmission / reception is performed by Ethernet (registered trademark) or the like generally used as a network connection method.
  • the first transmission / reception unit 310 performs data transmission / reception with a device connected downstream such as the HeNB 80
  • the second transmission / reception unit 320 realizes a function of performing data transmission / reception with a device connected upstream such as the PGW 20 or the MME 10.
  • the storage unit 330 is a functional unit that stores programs, data, and the like necessary for various operations of the SGW 30. Furthermore, an EPS bearer context 332 is stored in the storage unit 330.
  • FIG. 6 is a diagram showing an example of the EPS bearer context 332.
  • a UE identifier for example, “UE1”
  • a bearer ID for example, “bearer 1”
  • a UL TFT Uplink TFT
  • LIPA Local IP Access
  • FIG. 7 shows the configuration of the HeNB 80 in the present embodiment.
  • a network address translation (NAT) unit 810 In the HeNB 80, a network address translation (NAT) unit 810, an LTE base station unit 820, a storage unit 830, and a home network interface unit 840 are connected to the control unit 800 via a bus.
  • NAT network address translation
  • the control unit 800 is a functional unit for controlling the HeNB 80.
  • the control unit 800 implements processing by reading and executing various programs stored in the storage unit 830.
  • the NAT unit 810 receives the packet from the LTE base station unit 820, rewrites the transmission source IP address, and transfers the packet to the home network interface unit 840 based on the transmission destination IP address.
  • a packet is received from the home network interface unit 840, and the transmission destination IP address is rewritten and transferred to the LTE base station unit 820.
  • the LTE base station unit 820 functions as an E-UTRA base station and is a functional unit for accommodating UEs.
  • An external antenna 822 is connected to the LTE base station unit 820.
  • the storage unit 830 is a functional unit that stores programs, data, and the like necessary for various operations of the HeNB 80. Further, the storage unit 830 stores a multicast address setting table 832, a multicast group participation list 834, and an EPS bearer context 836.
  • FIG. 8 is a diagram showing an example of the multicast address setting table 832, which is a database that stores IP addresses of multicast groups that participate through local IP access.
  • FIG. 9 is a diagram showing an example of the multicast group participation list 834.
  • the multicast address for example, “FF02 :: C” and the identifier of the UE 90 participating in the multicast address group (for example, “UE1”) And the bearer ID (for example, “bearer 2”) used by the UE 90 for local IP access in association with each other, and manages UEs participating in the multicast address group on the home network 5 via the HeNB 80.
  • FIG. 10 is a diagram showing an example of the EPS bearer context 834.
  • FIG. 10A shows a UE identifier (for example, “UE1”), a bearer ID (for example, “bearer 1”), a LIPA setting (for example, “OFF”), similar to the EPS bearer context 134 of the MME 10.
  • UE1 UE identifier
  • bearer ID for example, “bearer 1”
  • LIPA setting for example, “OFF”
  • the HeNB 80 When the HeNB 80 receives a flow from the UE 90, the HeNB 80 checks which EPS bearer is used to transmit the flow. When the LIPA setting of the EPS bearer is “ON”, the HeNB 80 transmits the flow to the NAT unit 810. Via the home network interface unit 840 and directly into the home network 5. When the LIPA setting is “OFF”, the data is transferred to the SGW 30.
  • the home network interface unit 840 is a functional unit that performs packet transmission / reception with other devices in the home network 5. For example, transmission / reception is performed by Ethernet (registered trademark) or the like generally used as a network connection method.
  • the configuration of the UE 90 that is a mobile station apparatus in the present embodiment will be described.
  • a portable terminal connected to the mobile communication system via a radio access interface, a terminal such as a PDA, and the like are assumed.
  • an LTE interface unit 910 and a storage unit 930 are connected to the control unit 900 via a bus.
  • the control unit 900 is a functional unit for controlling the UE 90.
  • the control unit 900 implements various processes by reading and executing various programs stored in the storage unit 930.
  • the LTE interface unit 910 is a functional unit for the UE 90 to connect to the HeNB 80 and transmit / receive specific data (packets).
  • An external antenna 912 is connected to the LTE interface unit 910.
  • the storage unit 930 is a functional unit that stores programs, data, and the like necessary for various operations of the UE 90. Furthermore, an EPS bearer context 932 is stored in the storage unit 930.
  • FIG. 12 is a diagram showing an example of the EPS bearer context 932.
  • FIG. 12A stores a bearer ID (for example, “bearer ID 1”) and a UL TFT in association with each other, and manages the state of the EPS bearer established by the UE 90.
  • the UE 90 transmits a flow
  • the UL TFT to which the flow corresponds is searched, and when the corresponding UL TFT exists, the flow is transmitted using the EPS bearer associated with the UL TFT. To do.
  • FIG. 13 shows the configuration of the information terminal 70 in the present embodiment.
  • a home network interface unit 710 and a storage unit 730 are connected to the control unit 700 via a bus.
  • the control unit 700 is a functional unit for controlling the information terminal 70.
  • the control unit 700 implements various processes by reading and executing various programs stored in the storage unit.
  • the home network interface unit 710 is a functional unit that performs packet transmission / reception with other devices in the home network 5. For example, transmission / reception is performed by Ethernet (registered trademark) or the like generally used as a network connection method.
  • the storage unit 730 is a functional unit that stores programs, data, and the like necessary for various operations of the information terminal.
  • the UE 90 performs an attach process with the HeNB 80 according to the conventional method defined in Non-Patent Document 1 described above, and connects to the HeNB 80 (S100).
  • the UE 90 performs a PDN connection establishment process for the PGW 40 according to the conventional method (S102).
  • the PDN connection is a logical path established between the UE 90 and the PGW 40, and a plurality of EPS bearers can be established in one PDN connection.
  • the PDN connection establishment process is performed between the UE 90, the HeNB 80, the MME 10, the SGW 30, and the PGW 40.
  • the EPS bearer 1 that is a default bearer is established between the UE 90 and the PGW 40 (S104), and the EPS bearer context 134 of the MME 10 is set as shown in FIG. .
  • the EPS bearer context 332 of the SGW 30 is set as shown in FIG. 6 (A)
  • the EPS bearer context 836 of the HeNB 80 is set as shown in FIG. 10 (A)
  • the EPS bearer context 932 of the UE 90 is It is set as shown in FIG.
  • the default bearer is used for transmission / reception of a flow that is not associated with a specific EPS bearer.
  • the communication flow transmitted by the UE 90 is transmitted by the EPS bearer 1 according to the EPS bearer context 932 of the UE 90 (S106).
  • the trigger for starting the EPS bearer for local IP access may be a notification from a QoS management device in the core network such as PCRF (Policy and Charging Rules), or the completion of establishment of the PDN connection described above. May be started based on subscriber information that permits local IP access of the UE 90 in the subscriber management device in the core network, and is not limited to these, and other means may be used. Also good.
  • PCRF Policy and Charging Rules
  • the SGW 30 transmits a bearer establishment request to the MME 10 (S110).
  • the bearer establishment request includes identification information (UL TFT) of a communication flow to be subjected to local IP access, and an identifier (hereinafter, referred to as an instruction for performing communication by local IP access using the bearer requesting establishment). Called LIPA flag).
  • the UL TFT includes an IP address prefix (for example, “2001: 2: 3: 4 :: / 64” or the like) assigned to the home network.
  • the IP address prefix may be managed by a device in the core network 3 when the HeNB 80 is installed, and may be acquired by referring to such statically set information, or notified from the HeNB 80 to the SGW 30 by the connection procedure so far. For example, it may be set dynamically and acquired.
  • the MME 10 receives the bearer establishment request, and collates the usage authority with the subscription DB 132 using the CSG ID (CSG1) and the UE identifier of the HeNB 80 to which the UE 90 is connected according to the conventional method (S112).
  • the MME 10 sends a bearer establishment rejection to the SGW 30 and establishes the EPS bearer for local IP access. End the process.
  • the MME 10 allocates a new EPS bearer (bearer 2) to the UE 90 according to the received bearer establishment request, and updates the EPS bearer context 134 as shown in FIG. 4B (S114).
  • the bearer 2 is available for local IP access and the flow information communicated by the bearer 2 is stored.
  • the MME 10 generates a session management request.
  • the session management request includes the above-mentioned UL TFT and EPS bearer ID (bearer 2).
  • MME10 transmits the bearer setting request
  • the bearer setting request includes the bearer ID (bearer 2) of the EPS bearer used for local IP access and the LIPA flag.
  • the HeNB 80 receives the bearer setting request, and sets the routing information so that the communication flow received from the UE 90 by the EPS bearer 2 is not transferred to the SGW 30 but directly transmitted to the home network 5 to which the HeNB 80 is connected ( S118). Further, the EPS bearer context 836 is updated as shown in FIG. 10B (S120), and the bearer 2 is available for local IP access and the flow information communicated by the bearer 2 is stored. Furthermore, the session management request included in the bearer setting request is transferred to the UE 90 (S122).
  • the UE 90 sets the communication flow corresponding to the UL TFT to be transmitted to the HeNB 80 using the EPS bearer 2 in accordance with the UL TFT and EPS bearer ID included in the session management request (S124). Further, the EPS bearer context 932 is updated as shown in FIG. 12B, and the flow information communicated by the bearer 2 is stored. And a session management response is transmitted to HeNB80 (S126).
  • the HeNB 80 receives the session management response, includes the response in the bearer setting response, and transmits the response to the MME 10 (S128).
  • the MME 10 transmits a bearer establishment response including the bearer ID (bearer 2) of the established EPS bearer to the SGW 30 (S130).
  • the SGW 30 receives the bearer establishment response, updates the EPS bearer context 332 as shown in FIG. 6B (S132), the bearer 2 is available for local IP access, and the flow information communicated by the bearer 2 Remember.
  • communication data addressed to the UE 90 transmitted from the information terminal 70 is also performed via the HeNB 80 without going through the core network 3 in the same manner. Since the UE 90 performs communication using the IP address assigned by the PGW 40, there is a discrepancy with the IP address system in the home network 5, so that the HeNB 80 follows the NAT ( Network Address Translation) processing is performed to rewrite the IP address (S140, 142).
  • NAT Network Address Translation
  • the UE 90 transmits a multicast group join request according to the conventional method (S150).
  • the participation request is made by transmitting an IGMP join message or an MLD join message including the IP address (for example, “FF02 :: C” used in UPnP) of the multicast group to be joined.
  • the destination address is “FF02 :: 16” if it is IPv6, “224.0.0.22” if it is IPv4,
  • the bearer context 932 of the UE 90 Based on the EPS bearer context 932 of the UE 90, it is transmitted using the bearer 1.
  • the HeNB 80 transmits the packet transmitted using the bearer 1 to the SGW 30 as it is, but performs a multicast address acquisition process (S152) unlike the conventional one.
  • the HeNB 80 performs a multicast address acquisition process for all packets received from the UE 90. Accordingly, it is determined whether or not the packet transmitted by the UE 90 is a request to join the multicast group (S154). If the request is for joining a multicast group, a multicast address for identifying the multicast group is acquired. If it is not a request to join the multicast group, a received packet is transmitted to the SGW 30 and communication is performed as usual.
  • the multicast address acquisition process will be described with reference to FIG.
  • FIG. 16 is a diagram showing an operation flow of multicast address processing.
  • the HeNB 80 refers to the transmission destination address or protocol number of the packet received from the UE 90 (step S10).
  • the determination means determines by indicating multicast such as “FF02 :: 16” if the destination address of the packet is IPv6 and “224.0.0.22” if the packet is IPv4.
  • the determination is made by identifying the IGMP join message or the MLD join message by the protocol number or the like described in the header of the packet.
  • the HeNB 80 only determines whether or not the packet transmitted by the UE 90 is a multicast participation request based on this determination, and does not determine whether or not the packet is a request to participate in the multicast group of the home network.
  • IPv4 when “2” is specified as the protocol number, it is identified as a control message of the IGMP protocol, and when it is identified, it is described in the payload portion following the IP header. If “0x22” is specified as the message type, it is determined that the message is an IGMP join message.
  • IPv6 when “58” is designated as the protocol number, it is identified as a control message of the ICMP protocol, and when it is identified, it is described in the payload portion following the IP header
  • the type field is referred to and “143” is specified as the message type, it is determined that the message is an MLDjoin message.
  • the information element of the IP header is conventionally referred to, but the payload portion following the IP header is not referred to. Determine.
  • step S12 the HeNB 80 transmits the packet received from the UE 90 to the SGW 30 as usual, and ends the multicast address acquisition process (S18).
  • the multicast address is extracted with reference to the message content of the IGMP join message or the MLD join message (S14).
  • the SGW 30 connected by the bearer (bearer 1) connected to the core network with respect to the UE 90 is a default router, and the HeNB 80 transfers a packet transmitted from the UE 90 using the bearer 1 to the SGW 30 as it is. That is, although the information element of the IP header can be referred to, the payload portion following the IP header is not referred to, but here, unlike the conventional case, the multicast address is acquired by referring to the inside of the packet.
  • the HeNB 80 starts the multicast reception request determination process after acquiring the multicast address (S16), and ends the multicast address acquisition process.
  • the UE 90 can transmit the multicast participation request message without distinguishing whether the participating multicast group is the home network or the MBMS service.
  • the HeNB 80 acquires a multicast address from a multicast group join request message that has been transmitted to the SGW 30 as it is.
  • the multicast address acquisition process described above may be the following modification. A modification of the multicast packet acquisition process will be described with reference to FIGS.
  • the UE 90 does not require a new process, and unlike the conventional technique, the HeNB 80 refers to a payload part of an IP packet to acquire a multicast address. In the modification, the UE 90 also performs a new process in addition to the HeNB 80, so that the HeNB 80 acquires a multicast address without referring to the payload of the IP packet.
  • the UE 90 performs a multicast packet transmission process when the multicast participation request is transmitted in S150 described with reference to FIG. Processing will be described with reference to FIG.
  • the UE 90 confirms whether or not a LIPA connection is established (step S30). Whether or not the LIPA connection is established is confirmed by establishing a bearer for local IP access. Or you may confirm by managing a state that local IP access is possible by acquiring a LIPA flag from HeNB80 at the time of bearer establishment.
  • step S30 If the LIPA connection is not established (step S30; No), the multicast packet is transmitted as usual (step S34), and the multicast packet transmission process is terminated. Thereby, compatibility with the operation of the conventional UE 90 is ensured.
  • the multicast address is written in the transmission destination of the multicast participation request packet (step S32).
  • the packet destination address is “FF02 :: 16” if it is IPv6, “224.0.0.22” if it is IPv4, etc.
  • the multicast address is described in the payload portion below the IP header, but here, unlike the conventional case, the multicast address is described in the destination address.
  • step S34 a multicast packet is transmitted (step S34), and the multicast packet transmission process is terminated.
  • the HeNB 80 refers to the protocol number of the packet received from the UE 90 (step S50).
  • the determination means determines by identifying the IGMP join message or the MLD join message based on the protocol number described in the packet header.
  • the HeNB 80 only determines whether or not the packet transmitted by the UE 90 is a multicast participation request based on this determination, and does not determine whether or not the packet is a request to participate in the multicast group of the home network.
  • the HeNB 80 transmits the packet received from the UE 90 to the SGW 30 as usual, and ends the multicast address acquisition process (step S58).
  • the HeNB 80 confirms whether or not the UE 90 has a LIPA connection. If the HeNB 80 can confirm, the HeNB 80 extracts the transmission destination address of the packet transmitted by the UE 90 as a multicast address (step S54).
  • Whether the UE 90 is connected to the LIPA is confirmed by the UE 90 that a bearer for local IP access is established. Or you may confirm by managing a state that local IP access is possible by acquiring a LIPA flag from HeNB80 at the time of bearer establishment.
  • the multicast address may be acquired by referring to the payload following the IP header as described above.
  • the HeNB 80 extracts the IP address of the multicast group (step S54), starts the multicast reception request determination process (S56), and ends the multicast address acquisition process.
  • the multicast address can be acquired without referring to the payload portion following the IP header. Further, by confirming the presence or absence of LIPA connection, compatibility with the conventional multicast participation request procedure can be maintained.
  • the UE 90 can transmit a multicast participation request message without distinguishing whether the participating multicast group is for the home network or the MBMS service.
  • the HeNB 80 can acquire a multicast address from a multicast multicast participation request message that has been transmitted to the SGW 30 as it is.
  • a multicast reception request determination process is performed (S154).
  • the HeNB 80 determines whether the UE 90 requests participation in the multicast group of the home network or requests to participate in the multicast group of the MBMS service provided by the core network.
  • the multicast reception request determination process will be described below with reference to FIG.
  • step S 70 based on the multicast address setting table 832, it is confirmed whether or not the extracted IP address corresponds to the multicast address set for local IP access.
  • the multicast address setting table 832 manages multicast addresses set for local IP access, which is a multicast group in the home network.
  • the multicast address setting table 832 is statically set in advance by a user who manages the home network. Note that a multicast address used in the home network may be assigned throughout the communication system, and may be statically set in advance when the HeNB 80 is installed.
  • the multicast group participation request of the UE 90 is a request for multicast data reception in local IP access. It determines with having (step S72), and confirms whether UE90 has already established the EPS bearer for local IP access based on the EPS bearer context 836 (step S74).
  • step S74 If the establishment of the EPS bearer for local IP access can be confirmed (step S74; Yes), the multicast session establishment procedure for local IP access described below is started (step S78).
  • step S74 If the establishment of the EPS bearer for local IP access cannot be confirmed in step S74 (step S74; No), the HeNB 80 requests bearer establishment from the SGW 30 or the MME 10 and establishes the local IP access of the UE 90 described above. The process is first executed to establish a bearer (S76).
  • step S70 if the extracted IP address does not correspond to the multicast address set for local IP access (step S70; No), it is determined as a multicast participation request to the MBMS service of the core network (step S70). S80). Then, the conventional MBMS multi-session establishment process is started (step S82).
  • the procedure for establishing a multicast session for local IP access when it is determined that the request for participation in the multicast group of the home network is made by the multicast reception request determination process (S154).
  • the HeNB 80 transmits IGMP Join or MLD Join to the home network 5 in order to participate in the specified multicast address group (S162), and starts receiving data addressed to the specified multicast address (S164). Then, the HeNB 80 transmits a session management request to the UE 90 (S166).
  • the session management request is transmitted including the UL TFT and EPS bearer ID.
  • FF02 :: C which is the UL TFT of the participating multicast group
  • bearer 2 which is a bearer for local IP access
  • the UE 90 updates the EPS bearer context 932 as illustrated in FIG. 12C based on the UL TFT and the EPS bearer ID included in the session management request (S168), and transmits a session management response to the HeNB 80 (S170). ).
  • the HeNB 80 receives the session management response and completes the local IP access multicast session establishment procedure.
  • the HeNB 80 updates the EPS bearer context 836 as illustrated in FIG. 10C by transmitting and receiving the session management request and response.
  • the UE 90, the multicast address, and the bearer ID are added to the multicast group participation list 832.
  • the HeNB 80 refers to the multicast group participation list 834 as to whether or not the multicast address included in the participation request is a multicast address that the UE 90 has already received. If the multicast address is already received, the multicast session establishment procedure can be performed by omitting the transmission of the multicast participation request message (S162) and the multicast reception start (S164) by the HeNB 80.
  • the HeNB 80 sends a multicast participation request message to the SGW 30 as shown in FIG. Transmit (S180) and conventional MBMS processing is executed.
  • the SGW 30 transmits an MBMS notification request including the UE identifier and the multicast address to the MME 10 (S182), the MME 10 transmits an MBMS context activation start request to the UE (S184), the UE 90, the HeNB 80, the MME 10 Then, MBMS session establishment processing is performed between the SGW 30 and the MBMS-GW 50 (S186).
  • the multicast data reception process will be described with reference to FIG. 21, taking as an example the case where the UE 90 transmits and receives a service search request based on a service discovery protocol such as UPnP.
  • a service discovery protocol such as UPnP.
  • the UE 90 transmits a service search request. Since the transmission destination address of the service search request is “FF02 :: C”, the UE 90 selects a bearer (EPS bearer 2) based on the UL TFT of the EPS bearer context (S200), and sends the search request to the EPS bearer. 2 is transmitted (S202).
  • EPS bearer 2 based on the UL TFT of the EPS bearer context (S200)
  • the HeNB 80 determines the transfer destination based on the bearer ID (S204).
  • the service search request is received via the EPS bearer 2
  • it is decided to transfer directly to the home network based on the EPS bearer context 836, and after performing NAT processing (S206), on the home network 5
  • a service search request is multicast-transmitted (S208).
  • the information terminal 70 receives the service search request and multicast-transmits a service search response including information on the service to be provided (for example, “print service”) to “FF02 :: C” (S210).
  • the HeNB 80 receives the service search response, refers to the multicast group participation list 834, selects the transfer destination UE participating in the multicast group (S212), and selects the EPS bearer for local IP access of each UE. Then, a service search response is transmitted to the UE 90 using the selected EPS bearer (S216).
  • the received multicast data (here, the service search response) is discarded.
  • the UE 90 When the UE 90 itself provides a service, the UE 90 receives a service search request transmitted from the information terminal 70 via the HeNB 80, transmits a service search response to the HeNB 80 using the EPS bearer 2, and the HeNB 80 Transfer on the home network 5.
  • the HeNB 80 multicasts a service search request to “FF02 :: C”, so even if there are a plurality of information terminals on the home network 5, all the information is stored.
  • the terminal can receive it.
  • the HeNB 80 transmits the multicast participation request that is conventionally transmitted to the SGW 30. Determine whether the request is for requesting reception of multicast data with local IP access or request for reception of multicast data using conventional MBMS, and a suitable multicast session establishment procedure based on the determination result Can be selected.
  • UE 90 can receive multicast data even in a local IP access environment where MBMS is not introduced while maintaining compatibility with existing systems.
  • service discovery using multicast such as UPnP
  • the protocol can be operated without any changes.
  • the UE 90 since the UE 90 does not need to determine or process whether to participate in the multicast group by local IP access of the home network 5 or to join the multicast group of the MBMS service of the core network 3 for the multicast participation request transmission, The feature is that it is not necessary to impose these management and processing loads on the UE 90.
  • this embodiment can be realized without changing the processing of the SGW 30 and the MME 10.
  • the second embodiment is different only in the multicast session establishment procedure described with reference to FIG. 15 of the first embodiment, and the others are the same. Therefore, the multicast session establishment procedure of the second embodiment will be described using FIG. 22 in contrast with the first embodiment of FIG.
  • the HeNB 80 performs a multicast address acquisition process (S152) and a multicast reception request determination process (S154), and performs local IP access for the home network. Determine whether it is a request to join a multicast group.
  • the HeNB 80 transmits a multicast participation request in the home network (S162), and starts receiving the specified multicast data by participating in the multicast group. (S164).
  • the HeNB 80 and the UE 90 transmit and receive a session management request and response to update the bearer context (S166, S168, S170). Finally, multicast data transmission / reception processing is performed.
  • the second embodiment is different in that the HeNB 80 participates in the multicast group in advance before the UE 90 transmits the multicast participation request. The procedure will be described with reference to FIG.
  • the HeNB 80 transmits the multicast participation request to the home network before the UE 90 transmits the multicast participation request (S220), and starts receiving the designated multicast (S222). In this way, the HeNB 80 participates in advance in the multicast group set in the multicast address setting table 832.
  • the HeNB 80 performs a multicast address acquisition process (S226) and a multicast reception request determination process (S228), and a multicast group for local IP access of the home network 5 It is determined whether or not it is a request to join.
  • the HeNB 80 and the UE 90 transmit and receive a session management request and response to update the bearer context (S230, S232, S234), and finally multicast data
  • the transmission / reception process is performed.
  • the HeNB 80 participates in the multicast group in advance, and it is not necessary for the HeNB 80 to participate in the multicast group and receive it in response to the multicast participation request from the UE 90 as compared with the first embodiment. Therefore, since the time and processing from when the UE 90 transmits a multicast participation request to when multicast data transmission / reception is performed can be shortened, multicast data transmission / reception can be started quickly.
  • each message and the contents of each process in FIG. 20 are the same as those in the first embodiment, and detailed description thereof is omitted. If it is determined that the request is not a request to join the multicast group for local IP access of the home network 5 in the multicast reception request determination process (S228) The multicast participation request packet is transmitted to the SGW 30, and the MBMS service start procedure is performed in the same manner as in the first embodiment.
  • IPv6 communication using IPv6 has been described as an example.
  • the present invention can be similarly applied to communication using IPv4.
  • the program that operates in each device is a program that controls the CPU or the like (a program that causes a computer to function) so as to realize the functions of the above-described embodiments.
  • Information handled by these devices is temporarily stored in a temporary storage device (for example, RAM) at the time of processing, then stored in various ROM or HDD storage devices, and read and corrected by the CPU as necessary. • Writing is performed.
  • a recording medium for storing the program a semiconductor medium (for example, ROM, a nonvolatile memory card, etc.), an optical recording medium / a magneto-optical recording medium (for example, a DVD (Digital Versatile Disc), MO ((Magneto Optical Disc), MD (Mini Disc), CD (Compact Disc), BD, etc.), magnetic recording medium (for example, magnetic tape, flexible disk, etc.), etc.
  • the loaded program is executed.
  • the program when distributing to the market, can be stored in a portable recording medium for distribution, or transferred to a server computer connected via a network such as the Internet.
  • a server computer connected via a network such as the Internet.
  • the storage device of the server computer is also included in the present invention.
  • each device in the above-described embodiment may be realized as an LSI (Large Scale Integration) which is typically an integrated circuit.
  • LSI Large Scale Integration
  • Each functional block of each device may be individually formed as a chip, or a part or all of them may be integrated into a chip.
  • the method of circuit integration is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor.
  • integrated circuit technology that replaces LSI emerges due to advances in semiconductor technology, it is of course possible to use an integrated circuit based on this technology.

Landscapes

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

Abstract

　ホーム基地局装置が、移動局装置からマルチキャスト参加要求を受信し、受信されたマルチキャスト参加要求が、ホームネットワーク宛のマルチキャスト参加要求であるか否かを判定し、マルチキャスト参加要求がホームネットワーク宛と判定された場合には、前記移動局装置に対して、マルチキャストデータが送受信されるベアラを変更させるベアラ変更要求を送信する。これにより、ローカルＩＰアクセスをサポートするホーム基地局装置に接続している移動局装置がマルチキャストグループ参加要求を送信した場合に、当該要求がローカルＩＰアクセスでのマルチキャストデータ受信を要求する際には、好適なマルチキャストセッション確立することができる移動通信システム等を提供することとなる。

Description

移動通信システム、移動局装置、ホーム基地局装置及び通信方法
　本発明は、移動局装置が接続されたホーム基地局装置を有するホームネットワークと、位置管理装置及びアクセス制御装置が接続されるコアネットワークとが外部ネットワークを介して接続されている移動通信システム等に関する。
　移動通信システムの標準化団体３ＧＰＰ（The 3rd Generation Partnership Project）では、次世代の移動体通信システムとして以下の非特許文献１に記載のＥＰＳ（Evolved Packet System）の仕様化作業を進めており、ＥＰＳの構成装置として、宅内等に設置する小型基地局であるＨｅＮＢ（Home eNodeB：ホーム基地局）について検討がなされている。
　ＨｅＮＢは、フェムトセルと呼ばれる小規模の無線セルを構築し、通常の基地局と同じ無線アクセス技術を用いて、ＵＥ（User Equipment：移動端末装置）を収容する。そして、ブロードバンド回線を経由して移動通信システムのコアネットワークに接続し、収容しているＵＥの通信データを中継することができる。
　さらに以下の非特許文献２には、ＨｅＮＢでローカルＩＰアクセスを実現するためのアーキテクチャ候補が開示されている。ローカルＩＰアクセスとは、ＨｅＮＢが直接接続されている家庭内ＩＰネットワーク等のネットワーク（以下、「ホームネットワーク」と呼ぶ）へのダイレクトな接続性をＵＥに提供する機能であり、ＵＥは、移動通信システムのコアネットワークを経由せずに、ホームネットワークに接続している他の情報端末（例えば、デジタルビデオレコーダやプリンタ等）と通信することが可能となる。
　一方、ＥＰＳにおいて、ＵＥにコアネットワーク経由でのマルチキャストサービスを提供する方法として、ＭＢＭＳ（Multimedia Broadcast/Multicast Service）仕様が規定されている（例えば、非特許文献３参照）。
　ＭＢＭＳでは、移動通信システムのコアネットワーク内に、ＢＭ－ＳＣ（Broadcast-Multicast Service Centre）及びＭＢＭＳ－ＧＷ（Multimedia Broadcast/Multicast Service-Gateway）を設置し、ＢＭ－ＳＣとＭＢＭＳ－ＧＷと基地局とがマルチキャストデータの配信経路を確立することにより、ＵＥはマルチキャストデータの受信が可能となる。
　また、ホームネットワーク等のローカルエリアネットワーク（ＬＡＮ）内の装置同士が、互いに提供するサービス（例えばプリンタ装置が提供する「印刷サービス」など）を自動的に発見するための手法として、ＵＰｎＰ（Universal Plug and Play）等のマルチキャストを用いたサービス発見プロトコルがある（例えば、非特許文献４参照）。
　ユーザの利便性を考慮すると、ＵＰｎＰ等で実現される機能がローカルＩＰアクセス経由で接続しているＵＥでも利用できることが望ましいが、非特許文献２には、ローカルＩＰアクセスを用いたマルチキャストサービスの利用について要求条件としての記載はあるものの、その具体的な実現手段は記載されておらず、実現できなかった。
3GPP TS23.401 General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access 3GPP TR 23.829 Local IP Access and Selected IP Traffic Offload 3GPP TS 23.246 Multimedia Broadcast/Multicast Service; Architecture and functional description UPnP　Device Architecture 1.1
　非特許文献２で開示されるローカルＩＰアクセスを実現するアーキテクチャ候補では、ローカルＩＰアクセス仕様策定前に市場出荷されたＵＥについてもサポート対象とし、ＵＥに変更を加えずに実現するという要求条件が設定されている。
　従って、ＵＥは、通信データがコアネットワーク経由で転送されるか、ローカルＩＰアクセスを用いて転送されるかを関知せず、従来仕様に従って、ＴＦＴ（Traffic Flow Template）と呼ばれるフロー識別情報に基づいて、送信する通信データがどのＴＦＴに該当するかを見て、当該ＴＦＴに対応付けられているベアラ（ＱｏＳレベル毎にＵＥと基地局間で確立される論理パス）で送信するしかなかった。
　ＵＥがマルチキャストサービスを利用する場合には、非特許文献３に記載のマルチキャストグループ参加手続きに従って、ＩＰｖ４による通信の場合にはＩＧＭＰ（Internet Group Management Protocol ）　Ｊｏｉｎメッセージを、ＩＰｖ６による通信の場合にはＭＬＤ（Multicast Listener Discovery）　Ｊｏｉｎメッセージを送信してマルチキャストグループへ参加要求を行う。しかしながら、当該メッセージはどのマルチキャストグループに参加する場合であっても、同じアドレス宛（ＩＰｖ６であれば「ＦＦ０２：：１６」、ＩＰｖ４であれば「２２４．０．０．２２」）に送信する。
　そのため、宛先アドレスやプロトコル番号及びポート番号等で「フロー」を識別するＴＦＴだけでは、当該参加要求がローカルＩＰアクセスを用いたマルチキャストサービスへの要求であるか否かを振り分けてベアラを選択して送信することはできない。結果として、ＵＥはコアネットワークへ接続するベアラへ送信し、送信した参加要求メッセージはＵＥのデフォルトルータであるコアネットワーク内のＳＧＷ（Serving GW）と呼ばれるアクセス制御装置が受信するしかなかった。
　したがって、ＳＧＷをはじめとして、位置管理装置であるＭＭＥ（Mobility Management Entity）等のコアネットワーク内の装置によって、ＵＥの送信するマルチキャストグループ参加要求が、ローカルＩＰアクセスの参加要求であるか、ＭＢＭＳサービスのための参加要求メッセージであるかを判断し、ＵＥが要求したマルチキャスト通信を配送するための手続きを行う方法が考えられる。
　しかしながら、移動通信事業者が運用することが主に想定されるコアネットワーク内において、個々の利用者の家庭内で運用されているホームネットワーク毎のマルチキャストグループを管理する管理コストは膨大であり困難である。
　そのため、ＵＥの当該参加要求は、ホームネットワーク内に設置されるＨｅＮＢによってローカルＩＰアクセスの参加要求であるか、ＭＢＭＳサービスのための参加要求メッセージであるかを判断し、参加要求に応じてそれぞれのマルチキャストデータを受信するための手続きを行う必要がある。
　しかしながら、これまでＨｅＮＢでは、こうした判断手段がなく、さらにはこの判断に基づいたローカルＩＰアクセスでのマルチキャストデータを受信手段も、ＭＢＭＳサービスでのマルチキャストデータ受信手段もなかった。
　従って、上記の諸問題から、ＵＥは、ホームネットワークで提供されるマルチキャストサービスを享受できず、上述のＵＰｎＰ等の機能も利用することができなかった。
　本発明は、このような事情を鑑みてなされたもので、その目的は、ホーム基地局に接続している移動局装置は、ローカルＩＰアクセスでのマルチキャストグループか否かを検知せず同等の手段によってマルチキャスト参加要求を送信し、ホーム基地局が、移動局装置が参加要求するマルチキャストグループがホームネットワークで提供されるかコアネットワークで提供されるかを判定し、判定に応じて好適なマルチキャストセッションを確立することができる移動通信システム等を提供することである。
　上記課題を解決するために、本発明に係る移動通信システム等は、以下の特徴を備えている。
　本発明の移動通信システムは、移動局装置が接続されたホーム基地局装置を有するホームネットワークと、位置管理装置及びアクセス制御装置が接続されるコアネットワークとが外部ネットワークを介して接続されている移動通信システムであって、
　前記ホーム基地局装置は、
　前記移動局装置から送信されるマルチキャスト参加要求を受信するマルチキャスト参加要求受信手段と、
　前記マルチキャスト参加要求が、ホームネットワーク宛のマルチキャスト参加要求 であるか否かを判定するマルチキャスト参加要求判定手段と、
　前記マルチキャスト参加要求判定手段により、前記マルチキャスト参加要求がホームネットワーク宛と判定された場合には、前記移動局装置に対して、マルチキャストデータが送受信されるベアラを変更させるベアラ変更要求を送信するベアラ変更要求送信手段と、
　を備えることを特徴とする。
　また、本発明の移動通信システムにおいて、
　前記ホーム基地局装置は、
　ホームネットワーク宛のマルチキャスト参加要求となるアドレスを記憶するマルチキャストアドレス記憶手段を更に有し、
　前記マルチキャスト参加要求判定手段は、前記マルチキャスト参加要求に含まれるマルチキャストアドレスが、前記マルチキャストアドレス記憶手段に記憶されている場合には、ホームネットワーク宛のマルチキャスト要求であると判定することを特徴とする。
　また、本発明の移動通信システムにおいて、前記マルチキャスト参加要求判定手段により、前記マルチキャスト参加要求がホームネットワーク宛ではないと判定された場合には、前記マルチキャスト参加要求を、コアネットワークに送信することを特徴とする。
　また、本発明の移動通信システムにおいて、前記ホーム基地局装置は、ホームネットワークと通信を行う第１ベアラと、コアネットワークと通信を行う第２ベアラとを移動局装置と確立しており、
　前記マルチキャスト参加要求受信手段は、前記移動局装置から前記第２ベアラを経由して前記マルチキャスト参加要求を受信することを特徴とする。
　また、本発明の移動通信システムに接続される移動局装置は、前記ホーム基地局装置から、セッション管理要求を受信すると、マルチキャストデータを送受信するベアラを変更し、前記ホーム基地局装置を介してホームネットワークにおいてマルチキャストセッションを確立することを特徴とする。
　また、本発明の移動通信システムに接続される移動局装置は、
　ホームネットワークと通信を行う第１ベアラと、コアネットワークと通信を行う第２ベアラとを確立し、
　ホームネットワーク宛のマルチキャスト参加要求を、前記第２ベアラを経由して送信することを特徴とする。
　本発明のホーム基地局装置は、
　移動局装置が接続されたホーム基地局装置を有するホームネットワークと、位置管理装置及びアクセス制御装置が接続されるコアネットワークとが外部ネットワークを介して接続されている移動通信システムに接続されるホーム基地局装置であって、
　前記移動局装置からマルチキャスト参加要求を受信するマルチキャスト参加要求受信手段と、
　前記マルチキャスト参加要求が、ホームネットワーク宛のマルチキャスト要求であるか否かを判定するマルチキャスト参加要求判定手段と、
　前記マルチキャスト参加要求判定手段により、前記マルチキャスト要求がホームネットワーク宛と判定された場合には、前記移動局装置に対して、マルチキャストデータが送受信されるベアラを変更させるベアラ変更要求を送信するベアラ変更要求送信手段と、
　を備えることを特徴とする。
　本発明の通信方法は、
　移動局装置が接続されたホーム基地局装置を有するホームネットワークと、位置管理装置及びアクセス制御装置が接続されるコアネットワークとが外部ネットワークを介して接続されている移動通信システムにおける通信方法であって、
　前記ホーム基地局装置が、
　前記移動局装置から送信されるマルチキャスト参加要求を受信し、
　前記受信されたマルチキャスト参加要求が、ホームネットワーク宛のマルチキャスト参加要求であるか否かを判定し、
　前記マルチキャスト参加要求がホームネットワーク宛と判定された場合には、前記移動局装置に対して、マルチキャストデータが送受信されるベアラを変更させるベアラ変更要求を送信することを特徴とする。
　本発明によれば、既存システムとの互換性を維持しながら、好適なマルチキャストセッション確立手続きを選択することができ、ＵＥはローカルＩＰアクセス環境で提供されるマルチキャストサービスも利用することができる。
第１実施形態における移動体通信システムの構成図である。 第１実施形態におけるＭＭＥの構成図である。 第１実施形態におけるＭＭＥのサブスクリプションデータベースの一例を示す図である。 第１実施形態におけるＭＭＥのＥＰＳベアラコンテキストの一例を示す図である。 第１実施形態におけるＳＧＷの構成図である。 第１実施形態におけるＳＧＷのＥＰＳベアラコンテキストの一例を示す図である。 第１実施形態におけるＨｅＮＢの構成図である。 第１実施形態におけるＨｅＮＢのマルチキャストアドレス設定表の一例を示す図である。 第１実施形態におけるＨｅＮＢのマルチキャストグループ参加リストの一例を示す図である。 第１実施形態におけるＨｅＮＢのＥＰＳベアラコンテキストの一例を示す図である。 第１実施形態におけるＵＥの構成図である。 第１実施形態におけるＵＥのＥＰＳベアラコンテキストの一例を示す図である。 第１実施形態における情報端末の構成図である。 第１実施形態におけるＵＥのＨｅＮＢへのアタッチ処理及びローカルＩＰアクセス確立処理シーケンス例を示す図である。 第１実施形態におけるローカルＩＰアクセス用マルチキャストセッション確立処理シーケンス例を示す図である。 第１実施形態におけるＨｅＮＢのマルチキャストアドレス取得処理のフローチャート例を示す図である。 第１実施形態におけるＵＥのマルチキャストパケット送信処理のフローチャートの例を示す図である。 第１実施形態におけるＨｅＮＢのマルチキャストアドレス取得処理のフローチャートの変形例を示す図である。 第１実施形態におけＨｅＮＢのマルチキャスト受信要求判定処理のフローチャートを示す図である。 第１実施形態におけるＭＢＭＳ用マルチキャストセッション確立処理シーケンス例を示す図である。 第１実施形態におけるＵＥのマルチキャストデータ送受信処理シーケンス例を示す図である。 第２実施形態におけるローカルＩＰアクセス用マルチキャストセッション確立処理シーケンス例を示す図である。
　以下、図面を参照して本発明を実施するための最良の形態について説明する。なお、本実施形態では、一例として、本発明を適用した場合の移動通信システムの実施形態について、図を用いて詳細に説明する。
　［１．第１実施形態］
　まず、本発明を適用した第１実施形態について、図面を参照して説明する。
　［１．１　移動通信システムの概要］
　図１は、本実施形態における移動通信システム１の概略を説明するための図である。本図に示すように、移動通信システム１は、コアネットワーク３と、ホームネットワーク５と、ブロードバンドアクセスネットワーク７とから構成され、コアネットワーク３とホームネットワーク５とはブロードバンドアクセスネットワーク７を介して相互接続されている。
　ブロードバンドアクセスネットワーク７は、広帯域の通信を実現する有線アクセスネットワークであり、例えばＡＤＳＬ（Asymmetric Digital Subscriber Line）や光ファイバー等によって構築される。ただし、これに限らずＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）などの無線アクセスネットワークであっても良い。
　コアネットワーク３は、移動通信事業者が運用する移動通信ネットワークであり、ＭＭＥ１０と、ＧＷ２０と、ＳＧＷ３０と、ＰＧＷ（Packet data network GW）４０と、ＭＢＭＳ－ＧＷ５０とが配置されている。
　ＭＭＥ１０は、シグナリングを行うエンティティであり、移動局装置（ＵＥ９０）の位置管理及びＥＰＳベアラの確立手続きを主導する位置管理装置である。ＥＰＳベアラとは、ＵＥ毎にＰＧＷ４０とＵＥ９０との間で確立されるユーザＩＰパケットを転送する論理パスのことである。ＥＰＳベアラには、特定のＱｏＳレベルを設定することができ、またＴＦＴと関連付けられる。
　ＴＦＴは、通信データであるフローを識別するフィルター情報の集合で定義され、各フィルター情報に宛先アドレスやポート番号を指定することができる。したがって、ＴＦＴによって特定アプリケーションのトラフィックフローや特定の通信相手とのフローを識別することができる。
　ＧＷ２０は、ホームネットワーク５内に設置されているＨｅＮＢ８０と、コアネットワーク内装置との間でゲートウェイとして機能する。ＭＭＥ１０とＨｅＮＢ８０間、ＳＧＷ３０とＨｅＮＢ８０間及びＭＢＭＳ－ＧＷ５０とＨｅＮＢ８０間の通信は、ＧＷ２０を介して行われる。
　ＳＧＷ３０は、ＰＧＷ４０とＨｅＮＢ８０間でパケットを転送するアクセス制御装置である。なお、ＰＧＷ４０とＳＧＷ３０とは物理的に同一ノードで構成される場合もある。
　ＰＧＷ４０は、インターネット等の外部ＰＤＮ（Packet Data Network：パケット通信ネットワーク）と接続され、コアネットワーク３とそれらのＰＤＮとを接続するゲートウェイとして機能するとともに、ＵＥ９０の通信データをＳＧＷ３０に転送するゲートウェイ装置である。
　ＭＢＭＳ－ＧＷ５０は、ＭＢＭＳのマルチキャストデータをＨｅＮＢ８０に転送する装置であり、ＧＷ２０経由でＨｅＮＢ８０と接続され、ＭＭＥ１０とも接続されている。
　ホームネットワーク５は、家庭内のホームネットワークや企業などのコーポレートネットワークなどであり、ホームＧＷ６０と、情報端末７０と、ＨｅＮＢ８０と、ＵＥ９０とを含んで構成される。さらに、ホームネットワーク５は、ブロードバンドアクセスネットワーク７に接続されている。
　ホームＧＷ６０は、ホームネットワークとブロードバンドアクセスネットワーク間のゲートウェイ装置であり、ＡＤＳＬモデム内蔵ルータ等の従来のブロードバンドルータ装置である。
　情報端末７０は、ホームネットワーク５に接続されているＩＰ通信可能な機器であり、例えばプリンタ、デジタルビデオレコーダ又は家庭内に接続されるＰＣ等である。また、ＵＰｎＰに対応しており、提供するサービス（たとえば「印刷サービス」）をホームネットワーク内にアナウンスする。通常、複数の機器が接続可能であるが、本実施形態においては、説明の都合上情報端末７０一台を例にとって説明する。
　ＨｅＮＢ８０はホームネットワークに設置されながら、コアネットワーク事業者の提供する基地局としてＵＥを収容する。典型的には、フェムトセルを形成する３ＧＰＰ　ＬＴＥ（Long Term Evolution）の基地局などである。
　ＵＥ９０は、ＨｅＮＢに接続する移動通信端末であり、３ＧＰＰ　ＬＴＥの通信インタフェースなどを搭載して接続する。
　［１．２　装置構成］
　続いて、各装置構成について図を用いて簡単に説明する。なお、ＧＷ２０と、ＭＢＭＳ－ＧＷ５０と、ＰＧＷ４０とについては、ＥＰＳを利用した移動通信システムにおける従来の装置と同様に構成されているため、その詳細な説明を省略する。
　また、ホームＧＷ６０は、従来のブロードバンドルータ装置と同様に構成されているため、その詳細な説明を省略する。
　［１．２．１　ＭＭＥの構成］
　図２は、本実施形態におけるＭＭＥ１０の構成を示す。ＭＭＥ１０は、制御部１００に、送受信部１１０と、記憶部１３０とがバスを介して接続されている。
　制御部１００は、ＭＭＥ１０を制御するための機能部である。制御部１００は、記憶部１３０に記憶されている各種プログラムを読み出して実行することにより各種処理を実現する。
　送受信部１１０は、ルータもしくはスイッチに有線接続され、パケットの送受信を行う機能部である。例えば、ネットワークの接続方式として一般的に利用されているＥｔｈｅｒｎｅｔ（登録商標）等により送受信する。
　記憶部１３０は、ＭＭＥ１０の各種動作に必要なプログラム、データ等を記憶する機能部である。さらに、記憶部１３０には、サブスクリプションＤＢ（データベース）１３２と、ＥＰＳベアラコンテキスト１３４とが記憶されている。
　図３は、サブスクリプションＤＢ１３２の一例を示した図であり、ＵＥ識別子（例えば「ＵＥ１」）と、ＣＳＧ識別子（例えば「ＣＳＧ１」）と、ローカルＩＰアクセスの利用権限（例えば「許可」）とを対応付けて記憶するデータベースである。ＣＳＧ(Closed Subscriber Group）識別子とは、ＨｅＮＢ８０を一意に識別する識別子であり、サブスクリプションＤＢ１３２によって、どのＨｅＮＢ８０でローカルＩＰアクセスが利用できるかが決定される。
　図４は、ＥＰＳベアラコンテキスト１３６の一例を示した図である。例えば、図４（Ａ）に示すように、ＵＥ識別子（例えば「ＵＥ１」）と、ベアラＩＤ（例えば「ベアラ１」）と、ＵＬ　ＴＦＴ(Uplink TFT)（例えば、「総て」）と、ＬＩＰＡ(Local IP Access)設定（例えば、「ＯＦＦ」）とを対応付けて記憶し、ＵＥ９０毎に設定されているＥＰＳベアラの状態を管理する。
　ベアラＩＤは、ＥＰＳベアラを識別する識別子であり、ＬＩＰＡ設定は、それぞれのＥＰＳベアラでローカルＩＰアクセスを使用するか否かを示す。ＵＬ　ＴＦＴは、ＵＥ９０から送信されるフロー（アップリンクフロー）を識別する。
　ＥＰＳベアラコンテキスト１３４により、ＵＥ９０が確立しているベアラを把握することができ、さらにそれぞれのベアラに流れるフローを管理している。さらには、ベアラ毎にローカルＩＰアクセスを使用するかを管理している。例えば、図４（Ｂ）に示すように、ＵＥ１はローカルＩＰアクセスが可能なベアラ２を確立しており、ＵＬ　ＴＦＴに「宛先：２００１:２：３：４：：／６４」と指定して、ホームネットワークに接続する機器に宛てたフローはベアラ２を用いて通信すると管理する。
　［１．２．２　ＳＧＷの構成］
　続いて、本実施形態におけるＳＧＷ３０の構成を図５に示す。ＳＧＷ３０は、制御部３００に、第１送受信部３１０と、第２送受信部３２０と、記憶部３３０とがバスを介して接続されている。
　制御部３００は、ＳＧＷ３０を制御するための機能部である。制御部３００は、記憶部３３０に記憶されている各種プログラムを読み出して実行することにより処理を実現する。
　第１送受信部３１０及び第２送受信部は、他の装置に接続され、データの送受信を行う機能部である。例えば、ネットワークの接続方式として一般的に利用されているＥｔｈｅｒｎｅｔ（登録商標）などにより送受信する。ここで、第１送受信部３１０はＨｅＮＢ８０など下流に接続される装置とデータ送受信し、第２送受信部３２０は、ＰＧＷ２０やＭＭＥ１０など上流に接続された装置とデータ送受信する機能を実現する。
　記憶部３３０は、ＳＧＷ３０の各種動作に必要なプログラム、データ等を記憶する機能部である。さらに、記憶部３３０にはＥＰＳベアラコンテキスト３３２が記憶されている。
　図６は、ＥＰＳベアラコンテキスト３３２の一例を示した図である。例えば、図６（Ａ）に示すように、ＭＭＥ１０のＥＰＳベアラコンテキスト１３４と同様に、ＵＥ識別子（例えば「ＵＥ１」）と、ベアラＩＤ（例えば「ベアラ１」）と、ＵＬ　ＴＦＴ(Uplink TFT)（例えば「総て」）と、ＬＩＰＡ(Local IP Access)設定（例えば、「ＯＦＦ」）とを対応付けて記憶し、ＵＥ毎に設定されているＥＰＳベアラの状態を管理する。
　［１．２．３　ＨｅＮＢの構成］
　図７は、本実施形態におけるＨｅＮＢ８０の構成を示す。ＨｅＮＢ８０は、制御部８００に、ＮＡＴ（Network Address Translation）部８１０と、ＬＴＥ基地局部８２０と、記憶部８３０と、ホームネットワークインタフェース部８４０とがバスを介して接続されている。
　制御部８００は、ＨｅＮＢ８０を制御するための機能部である。制御部８００は、記憶部８３０に記憶されている各種プログラムを読み出して実行することにより処理を実現する。
　ＮＡＴ部８１０は、ＬＴＥ基地局部８２０からパケットを受信し、送信元ＩＰアドレスを書き換え、送信先ＩＰアドレスに基づいてホームネットワークインタフェース部８４０に転送する。
　また、同様にホームネットワークインタフェース部８４０からパケットを受信し、送信先ＩＰアドレスを書き換えてＬＴＥ基地局部８２０に転送する。
　ＬＴＥ基地局部８２０は、Ｅ－ＵＴＲＡの基地局として機能し、ＵＥを収容するための機能部である。また、ＬＴＥ基地局部８２０には、外部アンテナ８２２が接続されている。
　記憶部８３０は、ＨｅＮＢ８０の各種動作に必要なプログラム、データ等を記憶する機能部である。さらに記憶部８３０には、マルチキャストアドレス設定表８３２と、マルチキャストグループ参加リスト８３４とＥＰＳベアラコンテキスト８３６とが記憶されている。
　図８は、マルチキャストアドレス設定表８３２の一例を示した図であり、ローカルＩＰアクセス経由で参加するマルチキャストグループのＩＰアドレスを記憶するデータベースである。
　図９は、マルチキャストグループ参加リスト８３４の一例を示した図であり、マルチキャストアドレス（例えば「ＦＦ０２：：Ｃ」）と、当該マルチキャストアドレスグループに参加しているＵＥ９０の識別子（例えば、「ＵＥ１」）と、当該ＵＥ９０がローカルＩＰアクセスに用いるベアラＩＤ（例えば、「ベアラ２」）とを対応付けて記憶し、ＨｅＮＢ８０を介してホームネットワーク５上のマルチキャストアドレスグループに参加しているＵＥを管理する。
　図１０は、ＥＰＳベアラコンテキスト８３４の一例を示した図である。例えば、図１０（Ａ）は、ＭＭＥ１０のＥＰＳベアラコンテキスト１３４と同様に、ＵＥ識別子（例えば「ＵＥ１」）と、ベアラＩＤ（例えば「ベアラ１」）と、ＬＩＰＡ設定（例えば、「ＯＦＦ」）とを対応付けて記憶し、ＵＥ毎に設定されているＥＰＳベアラの状態を管理する。
　ＨｅＮＢ８０は、ＵＥ９０からフローを受信した際に、当該フローがどのＥＰＳベアラを用いて送信されたかを見て、当該ＥＰＳベアラのＬＩＰＡ設定が「ＯＮ」である場合には、当該フローをＮＡＴ部８１０経由でホームネットワークインタフェース部８４０からホームネットワーク５内に直接送信し、ＬＩＰＡ設定が「ＯＦＦ」である場合には、ＳＧＷ３０に転送する。
　ホームネットワークインタフェース部８４０は、ホームネットワーク５内の他装置とパケット送受信を行う機能部である。例えば、ネットワークの接続方式として一般的に利用されているＥｔｈｅｒｎｅｔ（登録商標）などにより送受信する。
　［１．２．４　ＵＥの構成］
　次に、本実施形態における移動局装置であるＵＥ９０の構成について説明する。ＵＥ９０の具体的な一例としては、無線アクセスインタフェースを介して移動通信システムに接続する携帯端末や、ＰＤＡ等の端末が想定される。図１１に示すように、制御部９００に、ＬＴＥインタフェース部９１０と、記憶部９３０とがバスを介して接続されている。
　制御部９００は、ＵＥ９０を制御するための機能部である。制御部９００は、記憶部９３０に記憶されている各種プログラムを読み出して実行することにより各種処理を実現する。
　ＬＴＥインタフェース部９１０は、ＵＥ９０がＨｅＮＢ８０に接続し、具体的なデータ（パケット）を送受信するための機能部である。また、ＬＴＥインタフェース部９１０には、外部アンテナ９１２が接続されている。
　記憶部９３０は、ＵＥ９０の各種動作に必要なプログラム、データ等を記憶する機能部である。さらに、記憶部９３０には、ＥＰＳベアラコンテキスト９３２が記憶されている。
　図１２は、ＥＰＳベアラコンテキスト９３２の一例を示した図である。例えば、図１２（Ａ）は、ベアラＩＤ（例えば「ベアラＩＤ１」）と、ＵＬ　ＴＦＴとを対応付けて記憶し、ＵＥ９０が確立しているＥＰＳベアラの状態を管理する。ＵＥ９０がフローを送信する場合には、フローがどのＵＬ　ＴＦＴに該当するかを検索し、該当するＵＬ　ＴＦＴが存在する場合には、当該ＵＬ　ＴＦＴに関連付けられているＥＰＳベアラを用いてフローを送信する。
　［１．２．５　情報端末の構成］
　図１３は、本実施形態における情報端末７０の構成を示す。情報端末７０は、制御部７００に、ホームネットワークインタフェース部７１０と、記憶部７３０とがバスを介して接続されている。
　制御部７００は、情報端末７０を制御するための機能部である。制御部７００は、記憶部に記憶されている各種プログラムを読み出して実行することにより各種処理を実現する。
　ホームネットワークインタフェース部７１０は、ホームネットワーク５内の他装置とパケット送受信を行う機能部である。例えば、ネットワークの接続方式として一般的に利用されているＥｔｈｅｒｎｅｔ（登録商標）等により送受信する。
　記憶部７３０は、情報端末の各種動作に必要なプログラム、データ等を記憶する機能部である。
　［１．３　処理の説明］
　次に、図１に示すネットワークにおいて、ＵＥ９０がＨｅＮＢ８０の提供するローカルＩＰアクセスを用いてマルチキャストデータを送受信するための手続きについて、図を用いて説明する。
　［１．３．１　ＵＥの接続処理］
　まず、ＵＥ９０はＨｅＮＢ８０にアタッチ処理を開始して接続する。このときの接続手続きについて、図１４を用いて詳細に説明する。
　ＵＥ９０は、上述した非特許文献１に規定された従来手法に従って、アタッチ処理をＨｅＮＢ８０との間で行い、ＨｅＮＢ８０に接続する（Ｓ１００）。
　さらに、ＵＥ９０は従来手法に従って、ＰＧＷ４０に対してＰＤＮコネクション確立処理を行う（Ｓ１０２）。ＰＤＮコネクションとは、ＵＥ９０とＰＧＷ４０との間で確立される論理パスであり、１つのＰＤＮコネクション内に複数のＥＰＳベアラを確立することができる。なお、ＰＤＮコネクション確立処理は、ＵＥ９０と、ＨｅＮＢ８０と、ＭＭＥ１０と、ＳＧＷ３０と、ＰＧＷ４０との間で行われる。
　ＰＤＮコネクション確立処理が完了すると、ＵＥ９０とＰＧＷ４０との間には、デフォルトベアラであるＥＰＳベアラ１が確立され（Ｓ１０４）、ＭＭＥ１０のＥＰＳベアラコンテキスト１３４は、図４（Ａ）のように設定される。
　また同様に、ＳＧＷ３０のＥＰＳベアラコンテキスト３３２は、図６（Ａ）のように設定され、ＨｅＮＢ８０のＥＰＳベアラコンテキスト８３６は、図１０（Ａ）のように設定され、ＵＥ９０のＥＰＳベアラコンテキスト９３２は、図１２（Ａ）のように設定される。なお、デフォルトベアラは、特定のＥＰＳベアラに関連付けられていないフローの送受信に用いられる。
　以後、ＵＥ９０が送信する通信フローは、ＵＥ９０のＥＰＳベアラコンテキスト９３２に従って、ＥＰＳベアラ１で送信される（Ｓ１０６）。
　［１．３．２　ＵＥのローカルＩＰアクセス確立処理］
　ＰＤＮコネクション確立処理を完了したＵＥ９０は、続けて、上述した非特許文献２に規定された従来手法に従って、ローカルＩＰアクセス用のＥＰＳベアラ確立を開始する。
　なお、このローカルＩＰアクセス用ＥＰＳベアラ確立を開始する契機は、例えばＰＣＲＦ（Policy and Charging Rules Function）等のコアネットワーク内のＱｏＳ管理装置からの通知であってもよいし、前述のＰＤＮコネクション確立完了に連動して行ってもよいし、コアネットワーク内の加入者管理装置におけるＵＥ９０のローカルＩＰアクセスを許可する加入者情報に基づいて開始してもよいし、これらに限らず他の手段を用いてもよい。
　まず、ＳＧＷ３０はベアラ確立要求をＭＭＥ１０に送信する（Ｓ１１０）。ベアラ確立要求には、ローカルＩＰアクセスを行う対象の通信フローの識別情報（ＵＬ　ＴＦＴ）と、当該確立要求するベアラを用いてローカルＩＰアクセスでの通信を行うことを指示するための識別子（以下、ＬＩＰＡフラグと呼ぶ）とを含める。ここで、ＵＬ　ＴＦＴには、ホームネットワークに割り当てられているＩＰアドレスプレフィックス（例えば、「２００１：２：３：４：：／６４」等）を含める。
　ＩＰアドレスプレフィックスは、ＨｅＮＢ８０設置時にコアネットワーク３内の装置において管理しておき、こうした静的に設定した情報を参照して取得してもよいし、これまでの接続手続きによってＨｅＮＢ８０からＳＧＷ３０へ通知するなどして、動的に設定して取得してもよい。
　ＭＭＥ１０は、ベアラ確立要求を受信し、従来方法に従って、ＵＥ９０が接続しているＨｅＮＢ８０のＣＳＧＩＤ（ＣＳＧ１）とＵＥ識別子とを用いて、サブスクリプションＤＢ１３２に利用権限を照合する（Ｓ１１２）。
　これにより、ＵＥ９０がＨｅＮＢ８０を用いたローカルＩＰアクセスの利用権限を持つかどうかを確認し、もし利用権限がない場合には、ＭＭＥ１０はベアラ確立拒否をＳＧＷ３０に送信し、ローカルＩＰアクセス用ＥＰＳベアラ確立処理を終了する。
　ＵＥ９０が利用権限を持つ場合には、受信したベアラ確立要求に従って、ＭＭＥ１０は、ＵＥ９０に新しいＥＰＳベアラ（ベアラ２）を割り当て、ＥＰＳベアラコンテキスト１３４を図４（Ｂ）のように更新し（Ｓ１１４）、ベアラ２がローカルＩＰアクセスに利用可能であることと、ベアラ２で通信するフロー情報を記憶する。
　さらに、ＭＭＥ１０はセッション管理要求を生成する。セッション管理要求には、前述のＵＬ　ＴＦＴとＥＰＳベアラＩＤ（ベアラ２）とを含める。そして、ＭＭＥ１０はセッション管理要求を含んだベアラ設定要求をＨｅＮＢ８０に送信する（Ｓ１１６）。ベアラ設定要求には、ローカルＩＰアクセスに用いるＥＰＳベアラのベアラＩＤ（ベアラ２）と、ＬＩＰＡフラグとが含まれる。
　ＨｅＮＢ８０は、ベアラ設定要求を受信し、ＥＰＳベアラ２でＵＥ９０から受信した通信フローについては、ＳＧＷ３０に転送せず、ＨｅＮＢ８０が接続しているホームネットワーク５に直接送信するようにルーティング情報を設定する（Ｓ１１８）。さらに、ＥＰＳベアラコンテキスト８３６を図１０（Ｂ）のように更新し（Ｓ１２０）、ベアラ２がローカルＩＰアクセスに利用可能であることと、ベアラ２で通信するフロー情報を記憶する。さらに、ベアラ設定要求に含まれていたセッション管理要求をＵＥ９０に転送する（Ｓ１２２）。
　ＵＥ９０は、セッション管理要求に含まれているＵＬ　ＴＦＴとＥＰＳベアラＩＤとに従って、ＵＬ　ＴＦＴに該当する通信フローについては、ＥＰＳベアラ２を用いてＨｅＮＢ８０に送信するように設定する（Ｓ１２４）。さらに、ＥＰＳベアラコンテキスト９３２を図１２（Ｂ）のように更新し、ベアラ２で通信するフロー情報を記憶する。そして、セッション管理応答をＨｅＮＢ８０に送信する（Ｓ１２６）。
　ＨｅＮＢ８０は、セッション管理応答を受信し、当該応答をベアラ設定応答に含めてＭＭＥ１０に送信する（Ｓ１２８）。
　ＭＭＥ１０は、確立したＥＰＳベアラのベアラＩＤ（ベアラ２）を含んだベアラ確立応答をＳＧＷ３０に送信する（Ｓ１３０）。
　ＳＧＷ３０は、ベアラ確立応答を受信し、ＥＰＳベアラコンテキスト３３２を図６（Ｂ）のように更新し（Ｓ１３２）、ベアラ２がローカルＩＰアクセスに利用可能であることと、ベアラ２で通信するフロー情報を記憶する。
　以上で、ＵＥ９０のローカルＩＰアクセス確立処理（ＥＰＳベアラ２）が完了する（Ｓ１３４）。これにより、ＵＥ９０が送信する通信フローのうち、ＵＬ　ＴＦＴで指定されたフロー識別情報に該当するフローについては、ＨｅＮＢ８０がコアネットワーク３に転送せず、直接ホームネットワーク５に転送するようになるため、ＵＥ９０はコアネットワーク３を経由せず情報端末７０と直接通信できるようになる。
　また、情報端末７０から送信されるＵＥ９０宛ての通信データについても同様にコアネットワーク３を経由することなく、ＨｅＮＢ８０を介して行われる。なお、ＵＥ９０はＰＧＷ４０から割り当てられたＩＰアドレスを用いて通信を行うため、ホームネットワーク５内のＩＰアドレス体系との齟齬が生じるので、ＨｅＮＢ８０は非特許文献２に記載された従来手法に従って、ＮＡＴ（Network Address Translation）処理を行い、ＩＰアドレスの書き換えを行う（Ｓ１４０、１４２）。
　［１．３．３　マルチキャストセッション確立処理（第１実施形態）］
　次に、ＵＥ９０はＵＰｎＰ等のサービス発見のためなど、ホームネットワーク５内で提供されているマルチキャストグループへ参加するため、マルチキャストグループへの参加手続きを行う。以下、図１５を用いて説明する。
　まず、ＵＥ９０は従来方法に従って、マルチキャストグループ参加要求を送信する（Ｓ１５０）。参加要求は、参加したいマルチキャストグループのＩＰアドレス（例えば、ＵＰｎＰで用いる「ＦＦ０２：：Ｃ」とする）を含んだＩＧＭＰｊｏｉｎメッセージ或いはＭＬＤｊｏｉｎメッセージを送信することによって行う。従来方法に従って、いずれのメッセージも参加要求するマルチキャストアドレスグループに関わらず、送信先アドレスは、ＩＰｖ６であれば、「ＦＦ０２：：１６」、ＩＰｖ４であれば「２２４．０．０．２２」となり、ＵＥ９０のＥＰＳベアラコンテキスト９３２に基づいて、ベアラ１を用いて送信される。
　従来では、ＨｅＮＢ８０は、ベアラ１を用いて送信されたパケットはそのままＳＧＷ３０に送信するが、従来とは異なり、マルチキャストアドレス取得処理を行う(Ｓ１５２)。
　ここで、ＨｅＮＢ８０は、ＵＥ９０から受信したパケットすべてに対してマルチキャストアドレス取得処理を行う。これにより、ＵＥ９０が送信したパケットがマルチキャストグループへの参加要求であるか否かを判定する（Ｓ１５４）。マルチキャストグループへの参加要求である場合には、マルチキャストグループを識別するマルチキャストアドレスを取得する。また、マルチキャストグループへの参加要求でない場合にはＳＧＷ３０へ受信パケットを送信し、従来通り通信を行う。以下、マルチキャストアドレス取得処理を、図１６を用いて説明する。
　［１．３．３．１　マルチキャストアドレス取得処理］
　図１６は、マルチキャストアドレス処理の動作フローを示した図である。ＨｅＮＢ８０は、ＵＥ９０から受信したパケットの送信先アドレス又はプロトコル番号を参照する（ステップＳ１０）。
　次に、ＵＥ９０から受信したパケットがマルチキャスト参加要求を示すものか否かを判定する(ステップＳ１２)。判定手段はパケットの送信先アドレスが、ＩＰｖ６であれば、「ＦＦ０２：：１６」、ＩＰｖ４であれば「２２４．０．０．２２」等、マルチキャストを示すことで判定する。又は、パケットのヘッダに記載されるプロトコル番号等により、ＩＧＭＰｊｏｉｎメッセージ或いはＭＬＤｊｏｉｎメッセージを識別することで判定する。ここで、ＨｅＮＢ８０はこの判定によって、ＵＥ９０が送信したパケットがマルチキャスト参加要求であるかどうかを判断するだけであり、ホームネットワークのマルチキャストグループへの参加要求であるか否かは判定しない。
　具体的にＩＰｖ４の場合では、例えばプロトコル番号として「２」が指定されている場合には、ＩＧＭＰプロトコルの制御メッセージであることを識別し、識別した場合にはＩＰヘッダに続くペイロード部分に記載されるタイプフィールドを参照し、メッセージタイプとして「０ｘ２２」が指定されている場合には、ＩＧＭＰｊｏｉｎメッセージであると判定する。
　また、ＩＰｖ６の場合では、例えばプロトコル番号として「５８」が指定されている場合には、ＩＣＭＰプロトコルの制御メッセージであることを識別し、識別した場合にはＩＰヘッダに続くペイロード部分に記載されるタイプフィールドを参照し、メッセージタイプとして「１４３」が指定されている場合には、ＭＬＤｊｏｉｎメッセージであると判定する。つまり、従来ではＩＰヘッダの情報要素は参照することはあってもＩＰヘッダ以下に続くペイロード部分を参照することはしないが、ここでは従来と異なりパケット内部を参照してマルチキャスト参加要求パケットであることを判定する。
　マルチキャスト参加要求を示すものでない場合（ステップＳ１２；Ｎｏ）、ＨｅＮＢ８０は、ＵＥ９０から受信したパケットを従来通りＳＧＷ３０へ送信し、マルチキャストアドレス取得処理を終了する（Ｓ１８）。
　ＵＥ９０が送信したパケットがマルチキャスト参加要求であると判定した場合は（ステップＳ１２；Ｙｅｓ）、ＩＧＭＰｊｏｉｎメッセージ又はＭＬＤｊｏｉｎメッセージのメッセージ内容を参照してマルチキャストアドレスを抽出する(Ｓ１４）。ＵＥ９０に対してコアネットワークへ接続するベアラ（ベアラ１)で接続されるＳＧＷ３０はデフォルトルータであり、ＨｅＮＢ８０はＵＥ９０がベアラ１を用いて送信するパケットは、ＳＧＷ３０へそのまま転送する。つまり、ＩＰヘッダの情報要素は参照することはあってもＩＰヘッダ以下に続くペイロード部分を参照することはしないが、ここでは従来と異なりパケット内部を参照してマルチキャストアドレスを取得する。
　ＨｅＮＢ８０は、マルチキャストアドレスを取得後、マルチキャスト受信要求判定処理を開始して(Ｓ１６)、マルチキャストアドレス取得処理を終了する。
　ＨｅＮＢ８０が、このマルチキャストアドレス取得処理行うことにより、ＵＥ９０は、参加するマルチキャストグループがホームネットワークのものかＭＢＭＳサービスのものかを区別することなくマルチキャスト参加要求メッセージを送信することができる。
　さらに、ＨｅＮＢ８０は、従来ＳＧＷ３０へそのまま送信されてしまうマルチキャストグループ参加要求メッセージからマルチキャストアドレスを取得する。ここで、上述したマルチキャストアドレス取得処理は、以下の変形例であってもよい。図１７、及び１８を用いて、マルチキャストパケット取得処理の変形例を説明する。
　［１．３．３．２　マルチキャストアドレス取得処理（変形例）］
　上述したマルチキャストアドレス取得処理では、ＵＥ９０に新たな処理を必要とせず、ＨｅＮＢ８０が従来とは異なりＩＰパケットのペイロード部分を参照してマルチキャストアドレスを取得する方法であった。変形例では、ＨｅＮＢ８０に加えてＵＥ９０も新たな処理を行うことで、ＨｅＮＢ８０がＩＰパケットのペイロードを参照することなくマルチキャストアドレスを取得する。
　ＵＥ９０は、図１５で説明したＳ１５０のマルチキャスト参加要求送信時、マルチキャストパケット送信処理を行う。図１７を用いて処理を説明する。
　最初にＵＥ９０は、ＬＩＰＡ接続をしているかどうかを確認する（ステップＳ３０）。ＬＩＰＡ接続をしているかどうかは、ローカルＩＰアクセス用のベアラが確立されていることで確認する。または、ベアラ確立時にＨｅＮＢ８０からＬＩＰＡフラグを取得することで、ローカルＩＰアクセス可能であると状態管理しておくことで確認してもよい。
　ＬＩＰＡ接続していない場合には（ステップＳ３０；Ｎｏ）、従来通りマルチキャストパケットを送信し（ステップＳ３４）、マルチキャストパケット送信処理を終了する。これにより、従来のＵＥ９０の動作との互換性が確保される。
　ＬＩＰＡ接続している場合には（ステップＳ３０；Ｙｅｓ）、マルチキャスト参加要求のパケットの送信先に、マルチキャストアドレスを記載する（ステップＳ３２）。マルチキャスト参加要求のための従来のＩＧＭＰｊｏｉｎメッセージ又はＭＬＤｊｏｉｎメッセージは、パケットの送信先アドレスは、ＩＰｖ６であれば、「ＦＦ０２：：１６」、ＩＰｖ４であれば「２２４．０．０．２２」等、マルチキャストを示すことアドレスであり、マルチキャストアドレスはＩＰヘッダ以下のペイロード部分に記載されるが、ここでは従来と異なり送信先アドレスにマルチキャストアドレスを記載する。
　その後、マルチキャストパケットを送信し（ステップＳ３４）、マルチキャストパケット送信処理を終了する。
　次に、図１５において、ＵＥ９０がマルチキャスト参加要求送信後（Ｓ１５０）のＨｅＮＢ８０のマルチキャストアドレス取得処理（Ｓ１５２）について、図１８を用いて説明する。
　まず、ＨｅＮＢ８０は、ＵＥ９０から受信したパケットのプロトコル番号を参照する（ステップＳ５０）。
　次に、ＵＥ９０から受信したパケットがマルチキャスト参加要求を示すものか否かを判定する(ステップＳ５２)。判定手段はパケットのヘッダに記載されるプロトコル番号により、ＩＧＭＰｊｏｉｎメッセージ又はＭＬＤｊｏｉｎメッセージを識別することで判定する。ここで、ＨｅＮＢ８０はこの判定によって、ＵＥ９０が送信したパケットがマルチキャスト参加要求であるかどうかを判定するだけであり、ホームネットワークのマルチキャストグループへの参加要求であるか否かは判定しない。
　マルチキャスト参加要求を示すものでない場合（ステップＳ５２；Ｎｏ）、ＨｅＮＢ８０は、ＵＥ９０から受信したパケットを従来通りＳＧＷ３０へ送信し、マルチキャストアドレス取得処理を終了する（ステップＳ５８）。
　ＵＥ９０が送信したパケットがマルチキャスト参加要求であると判定した場合は、
　ＨｅＮＢ８０は、ＵＥ９０がＬＩＰＡ接続をしているかを確認し、確認できた場合には、ＵＥ９０が送信したパケットの送信先アドレスをマルチキャストアドレスとして抽出する(ステップＳ５４）。
　ＵＥ９０がＬＩＰＡ接続しているかどうかは、ＵＥ９０が、ローカルＩＰアクセス用のベアラが確立されていることで確認する。又は、ベアラ確立時にＨｅＮＢ８０からＬＩＰＡフラグを取得することで、ローカルＩＰアクセス可能であると状態管理しておくことで確認してもよい。
　例えば、図１０のベアラコンテキストにおいて、ＵＥ９０がＬＩＰＡ設定「ＯＮ」のベアラを確立しているかどうかで判定可能である。また、ＬＩＰＡ設定が確認できない場合には、前述したようにＩＰヘッダに続くペイロードを参照してマルチキャストアドレスを取得してもよい。
　ＨｅＮＢ８０は、マルチキャストグループのＩＰアドレスを抽出し（ステップＳ５４）、マルチキャスト受信要求判定処理を開始して(Ｓ５６)、マルチキャストアドレス取得処理を終了する。
　この変形例では、前述したマルチキャストパケット取得処理とは異なり、ＩＰヘッダに続くペイロード部分を参照することなくマルチキャストアドレスを取得することができる。また、ＬＩＰＡ接続の有無を確認することで、従来のマルチキャスト参加要求手続きに対する互換性も保つことができる。
　このマルチキャストアドレス取得処理においても、ＵＥ９０は、参加するマルチキャストグループがホームネットワークのものかＭＢＭＳサービスのものかを区別することなくマルチキャスト参加要求メッセージを送信することができる。
　さらに、ＨｅＮＢ８０は、従来ＳＧＷ３０へそのまま送信されてしまうマルチキャストマルチキャスト参加要求メッセージからマルチキャストアドレスを取得することができる。
　図１５のマルチキャストセッション確立手続きに戻り、マルチキャストアドレス取得処理(Ｓ１５２)でマルチキャストアドレスが抽出できた場合、マルチキャスト受信要求判定処理を行う（Ｓ１５４）。マルチキャスト受信要求判定処理により、ＨｅＮＢ８０は、ＵＥ９０がホームネットワークのマルチキャストグループへの参加を要求しているか、コアネットワークの提供するＭＢＭＳサービスのマルチキャストグループに参加要求しているかを判定し、その後それぞれに応じた手続きを行う。マルチキャスト受信要求判定処理について、以下、図１９を用いて、説明する。
　［１．３．４　マルチキャスト受信要求判定処理］
　ここでは、受信したＭＢＭＳ通知要求内に含まれている参加要求マルチキャストグループのＩＰアドレスの「ＦＦ０２：：Ｃ」が抽出されるとする。
　次に、マルチキャストアドレス設定表８３２に基づいて、抽出したＩＰアドレスがローカルＩＰアクセス用に設定されたマルチキャストアドレスに該当するかを確認する（ステップＳ７０）。
　マルチキャストアドレス設定表８３２には、ホームネットワーク内のマルチキャストグループであるローカルＩＰアクセス用に設定されたマルチキャストアドレスが管理されている。マルチキャストアドレス設定表８３２は、ホームネットワークを管理するユーザが予め静的に設定しておくこととする。なお、ホームネットワークで利用されるマルチキャストアドレスを通信システム全体で割り当てておき、ＨｅＮＢ８０設置時に予め静的に設定されていてもよい。
　抽出したＩＰアドレスが、ローカルＩＰアクセス用に設定されたマルチキャストアドレスに該当する場合（ステップＳ７０；Ｙｅｓ）には、ＵＥ９０のマルチキャストグループ参加要求は、ローカルＩＰアクセスでのマルチキャストデータ受信を要求するものであると判定し（ステップＳ７２）、既にＵＥ９０がローカルＩＰアクセス用ＥＰＳベアラを確立しているか否かをＥＰＳベアラコンテキスト８３６に基づいて確認する（ステップＳ７４）。
　ローカルＩＰアクセス用ＥＰＳベアラの確立が確認できた場合（ステップＳ７４;Ｙｅｓ）には、次に説明するローカルＩＰアクセス用マルチキャストセッション確立手続きを開始する（ステップＳ７８）。
　なお、ステップＳ７４において、ローカルＩＰアクセス用ＥＰＳベアラの確立が確認できなかった場合（ステップＳ７４;Ｎｏ）には、ＨｅＮＢ８０は、ＳＧＷ３０又はＭＭＥ１０にベアラ確立を要求し、前述のＵＥ９０のローカルＩＰアクセス確立処理を先ず実行し、ベアラを確立する（Ｓ７６）。
　また、ステップＳ７０において、抽出されたＩＰアドレスがローカルＩＰアクセス用に設定されたマルチキャストアドレスに該当しない場合には（ステップＳ７０；Ｎｏ）、コアネットワークのＭＢＭＳサービスへのマルチキャスト参加要求と判定する（ステップＳ８０）。そして、従来のＭＢＭＳのマルチセッション確立処理を開始する（ステップＳ８２）。
　図１５に戻り、マルチキャスト受信要求判定処理(Ｓ１５４)により、ホームネットワークのマルチキャストグループへの参加要求と判定した場合の、ローカルＩＰアクセス用マルチキャストセッション確立手続きを説明する。
　［１．３．５　ローカルＩＰアクセス用マルチキャストセッション確立手続き］
　ＨｅＮＢ８０は、指定されたマルチキャストアドレスのグループへ参加するためにＩＧＭＰ　Ｊｏｉｎ又はＭＬＤ　Ｊｏｉｎをホームネットワーク５内に送信し（Ｓ１６２）、指定されたマルチキャストアドレス宛てのデータ受信を開始する（Ｓ１６４）。そして、ＨｅＮＢ８０はセッション管理要求をＵＥ９０に送信する（Ｓ１６６）。セッション管理要求には、ＵＬ　ＴＦＴとＥＰＳベアラＩＤを含めて送信する。ここでは、参加するマルチキャストグループのＵＬ　ＴＦＴである「ＦＦ０２：：Ｃ」と、ローカルＩＰアクセス用のベアラであるベアラ２を含めて送信する。
　ＵＥ９０は、セッション管理要求に含まれているＵＬ　ＴＦＴとＥＰＳベアラＩＤに基づいて、図１２（Ｃ）のようにＥＰＳベアラコンテキスト９３２を更新し（Ｓ１６８）、セッション管理応答をＨｅＮＢ８０に送信する（Ｓ１７０）。
ＨｅＮＢ８０は、セッション管理応答を受信し、以上でローカルＩＰアクセス用マルチキャストセッション確立手続きを完了する。ＨｅＮＢ８０は、セッション管理要求および応答の送受信により、図１０（Ｃ）のようにＥＰＳベアラコンテキスト８３６を更新する。
　さらに、マルチキャストグループ参加リスト８３２に、ＵＥ９０とマルチキャストアドレス及びベアラＩＤを追加する。これにより、ＵＥ９０とは異なる別のＵＥがマルチキャスト要求を送信した場合、ＨｅＮＢ８０は、参加要求に含まれるマルチキャストアドレスが、すでにＵＥ９０が受信しているマルチキャストアドレスか否かをマルチキャストグループ参加リスト８３４を参照して判断し、すでに受信しているマルチキャストアドレスであれば、ＨｅＮＢ８０によるマルチキャスト参加要求メッセージの送信（Ｓ１６２）およびマルチキャストの受信開始（Ｓ１６４）を省略してマルチキャストセッション確立手続きを行うことができる。
　一方、マルチキャスト受信要求判定（Ｓ１５４）において、ＵＥ９０が従来のＭＢＭＳを用いたマルチキャストデータ受信を要求していると判定された場合には、図２０に示すようにＨｅＮＢ８０はマルチキャスト参加要求メッセージをＳＧＷ３０へ送信し（Ｓ１８０）、従来のＭＢＭＳ処理が実行される。
　すなわち、ＳＧＷ３０は、ＵＥ識別子とマルチキャストアドレスを含めてＭＢＭＳ通知要求をＭＭＥ１０へ送信し（Ｓ１８２）、ＭＭＥ１０は、ＭＢＭＳコンテキスト活性化開始要求をＵＥに送信し（Ｓ１８４）、ＵＥ９０と、ＨｅＮＢ８０と、ＭＭＥ１０と、ＳＧＷ３０と、ＭＢＭＳ－ＧＷ５０との間でＭＢＭＳセッション確立処理を行う（Ｓ１８６）。
　［１．３．６　マルチキャストデータ受信処理］
　ローカルＩＰアクセス用マルチキャストセッションの確立が完了すると、ＵＥ９０はホームネットワーク５内で送信されたマルチキャストデータの受信が可能となる。
　以下、ＵＥ９０がＵＰｎＰ等のサービス発見プロトコルに基づいてサービス探索要求を送受信した場合を例に、マルチキャストデータ受信処理について、図２１を用いて説明する。
　まず、ＵＥ９０はサービス探索要求を送信する。サービス探索要求の送信先アドレスは、「ＦＦ０２：：Ｃ」であるため、ＵＥ９０は、ＥＰＳベアラコンテキストのＵＬ　ＴＦＴに基づいてベアラ（ＥＰＳベアラ２）を選択し（Ｓ２００）、当該探索要求をＥＰＳベアラ２で送信する（Ｓ２０２）。
　ＨｅＮＢ８０は、ベアラＩＤで転送先を判定する（Ｓ２０４）。ここでは、ＥＰＳベアラ２経由でサービス探索要求を受信するので、ＥＰＳベアラコンテキスト８３６に基づいてホームネットワークに直接転送することを決定し、ＮＡＴ処理を行ったうえで（Ｓ２０６）、ホームネットワーク５上でサービス探索要求をマルチキャスト送信する（Ｓ２０８）。
　情報端末７０は、上記サービス探索要求を受信し、提供するサービスの情報（例えば「印刷サービス」）を含んだサービス探索応答を「ＦＦ０２：：Ｃ」宛てにマルチキャスト送信する（Ｓ２１０）。
　ＨｅＮＢ８０は、サービス探索応答を受信し、マルチキャストグループ参加リスト８３４を参照し、当該マルチキャストグループに参加している転送先のＵＥを選択し（Ｓ２１２）、各ＵＥのローカルＩＰアクセス用のＥＰＳベアラを選択し（Ｓ２１４）、選択したＥＰＳベアラを用いてＵＥ９０にサービス探索応答を送信する（Ｓ２１６）。
　なお、ＨｅＮＢ８０がマルチキャストグループ参加リスト８３４を参照した結果、当該マルチキャストグループに参加しているＵＥ９０が見つからなかった場合には、受信したマルチキャストデータ（ここでは、サービス探索応答）を破棄する。
　また、ＵＥ９０自体がサービスを提供している場合には、ＵＥ９０は、情報端末７０が送信するサービス探索要求をＨｅＮＢ８０経由で受信し、サービス検索応答をＥＰＳベアラ２を用いてＨｅＮＢ８０に送信し、ＨｅＮＢ８０がホームネットワーク５上に転送する。
　なお、本実施形態では、ホームネットワーク５上に情報端末７０のみが存在する場合を例に述べたが、それに限らず複数の情報端末が存在する場合であっても同様に動作する。具体的には、Ｓ２０８において、ＨｅＮＢ８０はサービス探索要求を「ＦＦ０２：：Ｃ」宛てにマルチキャスト送信するので、ホームネットワーク５上に複数の情報端末が存在する場合であっても、その総ての情報端末が受信することができる。
　このように、本実施形態では、ローカルＩＰアクセス機能を持つＨｅＮＢ８０に接続しているＵＥ９０がマルチキャストグループ参加要求を送信した場合、従来ＳＧＷ３０へ送信されてしまうマルチキャスト参加要求を、ＨｅＮＢ８０が、当該マルチキャスト参加要求がローカルＩＰアクセスでのマルチキャストデータ受信を要求するものであるか、或いは従来のＭＢＭＳを用いたマルチキャストデータ受信を要求するものであるかを判定し、判定結果に基づいて好適なマルチキャストセッション確立手続きを選択することができる。
　これにより、既存システムとの互換性を維持しながら、ＭＢＭＳが導入されていないローカルＩＰアクセス環境においても、ＵＥ９０がマルチキャストデータの受信を行うことができ、例えば、ＵＰｎＰ等のマルチキャストを用いたサービス発見プロトコルについても何ら変更を加えることなく動作させることができる。
　さらに、ＵＥ９０は、マルチキャスト参加要求送信に対して、ホームネットワーク５のローカルＩＰアクセスによるマルチキャストグループに参加するか、コアネットワーク３のＭＢＭＳサービスのマルチキャストグループに参加するかの判断や処理を必要しないため、ＵＥ９０にこれらの管理、処理負荷を課す必要が無いことが特徴である。
　また、本実施形態では、コアネットワーク内の装置において、ホームネットワーク５のローカルＩＰアクセスによるマルチキャストグループに参加するか、コアネットワーク３のＭＢＭＳサービスのマルチキャストグループに参加するかの判定処理を必要としない。つまり、ＳＧＷ３０、ＭＭＥ１０の処理に変更を加えることなく、本実施形態を実現することができる。
　［２．第２実施形態］
　続いて、本発明を適用した第２実施形態について説明する。本実施形態は、ネットワーク構成及び装置構成は第１実施形態と同様であり、詳細な説明は省略する。
　［２．１　処理の説明］
　第２実施形態は、第１実施形態の図１５を用いて説明したマルチキャストセッション確立手続きのみに違いがあり、その他は同様である。そのため、図２２を用いて、第２実施形態のマルチキャストセッション確立手続きを、図１５の第１実施形態と対比させながら説明する。
　図１５の第１実施形態では、ＵＥ９０のマルチキャスト参加要求送信後（Ｓ１５０）、ＨｅＮＢ８０は、マルチキャストアドレス取得処理（Ｓ１５２）およびマルチキャスト受信要求判定処理（Ｓ１５４）を行い、ホームネットワークのローカルＩＰアクセス用のマルチキャストグループへの参加要求であるかを判定する。
　ホームネットワークのローカルＩＰアクセス用のマルチキャストグループへの参加要求である場合、ＨｅＮＢ８０は、ホームネットワーク内にマルチキャスト参加要求を送信し(Ｓ１６２)、マルチキャストグループに参加して指定されたマルチキャストデータの受信を開始する(Ｓ１６４)。
　その後、ＨｅＮＢ８０とＵＥ９０はセッション管理要求、応答を送受信してベアラコンテキストの更新を行う（Ｓ１６６、Ｓ１６８、Ｓ１７０）。そして最後にマルチキャストデータの送受信処理が行われる。
　一方で、第２実施形態では、ＨｅＮＢ８０は、ＵＥ９０がマルチキャスト参加要求を送信する以前に予めマルチキャストグループへ参加しておく点が異なる。図２２を用いて手続きを説明する。
　ＨｅＮＢ８０は、ＵＥ９０がマルチキャスト参加要求を送信する前に、マルチキャスト参加要求をホームネットワークへ送信し(Ｓ２２０)、指定したマルチキャストの受信を開始する（Ｓ２２２）。こうして、ＨｅＮＢ８０は、マルチキャストアドレス設定表８３２に設定されたマルチキャストグループに予め参加しておく。
　その後、ＵＥ９０からマルチキャスト参加要求を受信した場合には（Ｓ２２４）、ＨｅＮＢ８０は、マルチキャストアドレス取得処理（Ｓ２２６）およびマルチキャスト受信要求判定処理（Ｓ２２８）を行い、ホームネットワーク５のローカルＩＰアクセス用のマルチキャストグループへの参加要求であるかを判定する。
　ホームネットワーク５のローカルＩＰアクセス用のマルチキャストグループへの参加要求である場合、ＨｅＮＢ８０とＵＥ９０はセッション管理要求、応答を送受信してベアラコンテキストの更新を行い（Ｓ２３０、Ｓ２３２、Ｓ２３４）、最後にマルチキャストデータの送受信処理が行われる。
　第２実施形態では、ＨｅＮＢ８０がマルチキャストグループへ予め参加しており、第１実施形態と比較して、ＵＥ９０のマルチキャスト参加要求を契機に、ＨｅＮＢ８０がマルチキャストグループへ参加して受信する必要が無い。そのため、ＵＥ９０がマルチキャスト参加要求を送信してからマルチキャストデータ送受信を行うまでの時間および処理を短縮することができるため、速やかにマルチキャストデータ送受信を開始することができる。
　また、図２０での各メッセージの内容や各処理の内容は第１実施形態と同様であり、詳細な説明は省略するが、マルチキャストアドレス取得処理（Ｓ２２６）でＵＥ９０が送信したパケットがマルチキャスト参加要求を示すものではない場合には、ＳＧＷ３０へ従来通り送信することや、マルチキャスト受信要求判定処理（Ｓ２２８）において、ホームネットワーク５のローカルＩＰアクセス用のマルチキャストグループへの参加要求でないと判断した場合には、マルチキャスト参加要求パケットをＳＧＷ３０へ送信して、ＭＢＭＳサービスの開始手続きは、第１実施形態と同様に行うものである。
　［３．変形例］
　以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も特許請求の範囲に含まれる。
　また、各実施形態において、ＩＰｖ６を用いた通信を例に述べたが、ＩＰｖ４のマルチキャストアドレスを基にマルチキャスト参加要求をすることで、ＩＰｖ４での通信においても同様に適用できる。
　また、各実施形態において各装置で動作するプログラムは、上述した実施形態の機能を実現するように、ＣＰＵ等を制御するプログラム（コンピュータを機能させるプログラム）である。そして、これら装置で取り扱われる情報は、その処理時に一時的に一時記憶装置（例えば、ＲＡＭ）に蓄積され、その後、各種ＲＯＭやＨＤＤの記憶装置に格納され、必要に応じてＣＰＵによって読み出し、修正・書き込みが行なわれる。
　ここで、プログラムを格納する記録媒体としては、半導体媒体（例えば、ＲＯＭや、不揮発性のメモリカード等）、光記録媒体・光磁気記録媒体（例えば、ＤＶＤ（Digital Versatile Disc）、ＭＯ（(Magneto Optical Disc）、ＭＤ（Mini Disc）、ＣＤ（Compact Disc）、ＢＤ等）、磁気記録媒体（例えば、磁気テープ、フレキシブルディスク等）等のいずれであってもよい。また、ロードしたプログラムを実行することにより、上述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、オペレーティングシステムあるいは他のアプリケーションプログラム等と共同して処理することにより、本発明の機能が実現される場合もある。
　また、市場に流通させる場合には、可搬型の記録媒体にプログラムを格納して流通させたり、インターネット等のネットワークを介して接続されたサーバコンピュータに転送したりすることができる。この場合、サーバコンピュータの記憶装置も本発明に含まれるのは勿論である。
　また、上述した実施形態における各装置の一部又は全部を典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現してもよい。各装置の各機能ブロックは個別にチップ化してもよいし、一部、または全部を集積してチップ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、または汎用プロセッサで実現しても良い。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いることも可能であることは勿論である。
１　移動通信システム
　３　コアネットワーク
　　１０　ＭＭＥ
　　　１００　制御部
　　　１１０　送受信部
　　　１３０　記憶部
　　　　１３２　サブスクリプションＤＢ
　　　　１３４　ＥＰＳベアラコンテキスト
　　２０　ＧＷ
　　３０　ＳＧＷ
　　　３００　制御部
　　　３１０　第１送受信部
　　　３２０　第２送受信部
　　　３３０　記憶部
　　　　３３２　ＥＰＳベアラコンテキスト
　　４０　ＰＧＷ
　　５０　ＭＢＭＳ－ＧＷ
　５　ホームネットワーク
　　６０　ホームＧＷ
　　７０　情報端末
　　　７００　制御部
　　　７１０　ホームネットワークインタフェース部
　　　７３０　記憶部
　　８０　ＨｅＮＢ
　　　８００　制御部
　　　８１０　ＮＡＴ部
　　　８２０　ＬＴＥ基地局部
　　　　８２２　外部アンテナ
　　　８３０　記憶部
　　　　８３２　マルチキャストアドレス設定表
　　　　８３４　マルチキャストグループ参加リスト
　　　　８３６　ＥＰＳベアラコンテキスト
　　　８４０　ホームネットワークインタフェース部
　　９０　ＵＥ
　　　９００　制御部
　　　９１０　ＬＴＥインタフェース部
　　　　９１２　外部アンテナ
　　　９３０　記憶部
　　　　９３２　ＥＰＳベアラコンテキスト
　７　ブロードバンドアクセスネットワーク

Claims (8)

  1. 　移動局装置が接続されたホーム基地局装置を有するホームネットワークと、位置管理装置及びアクセス制御装置が接続されるコアネットワークとが外部ネットワークを介して接続されている移動通信システムであって、
    　前記ホーム基地局装置は、
    　前記移動局装置から送信されるマルチキャスト参加要求を受信するマルチキャスト参加要求受信手段と、
    　前記マルチキャスト参加要求が、ホームネットワーク宛のマルチキャスト参加要求であるか否かを判定するマルチキャスト参加要求判定手段と、
    　前記マルチキャスト参加要求判定手段により、前記マルチキャスト参加要求がホームネットワーク宛と判定された場合には、前記移動局装置に対して、マルチキャストデータが送受信されるベアラを変更させるベアラ変更要求を送信するベアラ変更要求送信手段と、
    　を備えることを特徴とする移動通信システム。
  2. 　前記ホーム基地局装置は、
    　ホームネットワーク宛のマルチキャスト参加要求となるアドレスを記憶するマルチキャストアドレス記憶手段を更に有し、
    　前記マルチキャスト参加要求判定手段は、前記マルチキャスト参加要求に含まれるマルチキャストアドレスが、前記マルチキャストアドレス記憶手段に記憶されている場合には、ホームネットワーク宛のマルチキャスト要求であると判定することを特徴とする請求項１に記載の移動通信システム。
  3. 　前記マルチキャスト参加要求判定手段により、前記マルチキャスト参加要求がホームネットワーク宛ではないと判定された場合には、前記マルチキャスト参加要求を、コアネットワークに送信することを特徴とする請求項１又は２に記載の移動通信システム。
  4. 　前記ホーム基地局装置は、ホームネットワークと通信を行う第１ベアラと、コアネットワークと通信を行う第２ベアラとを移動局装置と確立しており、
    　前記マルチキャスト参加要求受信手段は、前記移動局装置から前記第２ベアラを経由して前記マルチキャスト参加要求を受信することを特徴とする請求項１から３の何れかに記載の移動通信システム。
  5. 　請求項１から４の何れかに記載の移動通信システムに接続される移動局装置であって、
    　前記ホーム基地局装置から、セッション管理要求を受信すると、マルチキャストデータを送受信するベアラを変更し、前記ホーム基地局装置を介してホームネットワークにおいてマルチキャストセッションを確立することを特徴とする移動局装置。
  6. 　請求項１から３の何れかに記載の移動通信システムに接続される移動局装置であって、
    　ホームネットワークと通信を行う第１ベアラと、コアネットワークと通信を行う第２ベアラとを確立し、
    　ホームネットワーク宛のマルチキャスト参加要求を、前記第２ベアラを経由して送信することを特徴とする移動局装置。
  7. 　移動局装置が接続されたホーム基地局装置を有するホームネットワークと、位置管理装置及びアクセス制御装置が接続されるコアネットワークとが外部ネットワークを介して接続されている移動通信システムに接続されるホーム基地局装置であって、
    　前記移動局装置からマルチキャスト参加要求を受信するマルチキャスト参加要求受信手段と、
    　前記マルチキャスト参加要求が、ホームネットワーク宛のマルチキャスト要求であるか否かを判定するマルチキャスト参加要求判定手段と、
    　前記マルチキャスト参加要求判定手段により、前記マルチキャスト要求がホームネットワーク宛と判定された場合には、前記移動局装置に対して、マルチキャストデータが送受信されるベアラを変更させるベアラ変更要求を送信するベアラ変更要求送信手段と、
    　を備えることを特徴とするホーム基地局装置。
  8. 　移動局装置が接続されたホーム基地局装置を有するホームネットワークと、位置管理装置及びアクセス制御装置が接続されるコアネットワークとが外部ネットワークを介して接続されている移動通信システムにおける通信方法であって、
    　前記ホーム基地局装置が、
    　前記移動局装置から送信されるマルチキャスト参加要求を受信し、
    　前記受信されたマルチキャスト参加要求が、ホームネットワーク宛のマルチキャスト参加要求であるか否かを判定し、
    　前記マルチキャスト参加要求がホームネットワーク宛と判定された場合には、前記移動局装置に対して、マルチキャストデータが送受信されるベアラを変更させるベアラ変更要求を送信することを特徴とする通信方法。
PCT/JP2011/068964 2010-08-23 2011-08-23 移動通信システム、移動局装置、ホーム基地局装置及び通信方法 WO2012026461A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2010186581A JP2012044619A (ja) 2010-08-23 2010-08-23 移動通信システム、移動局装置、ホーム基地局装置及び通信方法
JP2010-186581 2010-08-23

Publications (1)

Publication Number Publication Date
WO2012026461A1 true WO2012026461A1 (ja) 2012-03-01

Family

ID=45723455

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/068964 WO2012026461A1 (ja) 2010-08-23 2011-08-23 移動通信システム、移動局装置、ホーム基地局装置及び通信方法

Country Status (2)

Country Link
JP (1) JP2012044619A (ja)
WO (1) WO2012026461A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170122640A (ko) * 2015-02-27 2017-11-06 소니 주식회사 수신 장치, 수신 방법, 송신 장치 및 송신 방법

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006528455A (ja) * 2003-07-28 2006-12-14 サムスン エレクトロニクス カンパニー リミテッド マルチメディアブロードキャスト／マルチキャストサービス（ｍｂｍｓ）を提供する符号分割多重接続移動通信システムにおけるソフトコンバイニング装置及び方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006528455A (ja) * 2003-07-28 2006-12-14 サムスン エレクトロニクス カンパニー リミテッド マルチメディアブロードキャスト／マルチキャストサービス（ｍｂｍｓ）を提供する符号分割多重接続移動通信システムにおけるソフトコンバイニング装置及び方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Local IP Access and Selected IP Traffic Offload (Release 10)", 3GPP 23.829 V1.1.0, 3GPP, May 2010 (2010-05-01) *
TELECOM ITALIA, SAMSUNG: "Multicast support with LIPA", S2-097464, 3GPP, 20 November 2009 (2009-11-20) *

Also Published As

Publication number Publication date
JP2012044619A (ja) 2012-03-01

Similar Documents

Publication Publication Date Title
WO2019091456A1 (zh) 一种传输组播业务的方法和设备
US9743437B2 (en) Mobile communication system
WO2021227650A1 (zh) Ue执行的方法及ue、以及smf实体执行的方法及smf实体
DK2074842T3 (en) Efficient MBMS backbone distribution using a single tunnel access
JP6483617B2 (ja) 端末装置、リレー端末装置および通信制御方法
EP3364676B1 (en) Method for supporting pdn gw selection
US20130215815A1 (en) Efficient multicast control processing for a wireless network
JPH10243010A (ja) 移動ホストのマルチキャスト通信方法
US9461848B2 (en) Gateway device, mobile communication system, mobile terminal, packet transfer control method, control method of mobile terminal, and non-transitory computer readable medium
WO2008025243A1 (fr) PASSERELLE D'ACCÈS, eNB ET PROCÉDÉ POUR SERVICE ÉVOLUÉ DE MULTIDIFFUSION EN DIFFUSION MULTIMÉDIA
WO2011083729A1 (ja) 移動通信システム、モビリティ管理装置、データ配信装置、移動通信方法及びプログラム
JP5246372B2 (ja) 移動通信システム、マルチキャストデータ配信方法、コアネットワークノード、アクセスネットワークノード、および端末
WO2016150140A1 (zh) 一种基于sdn的网关中控制报文的处理方法及系统
JPWO2007123227A1 (ja) マルチキャストパケット転送装置及びマルチキャストパケット管理装置並びにマルチキャストパケット受信装置
JP5676974B2 (ja) ホーム基地局装置及び移動局装置
WO2012026461A1 (ja) 移動通信システム、移動局装置、ホーム基地局装置及び通信方法
JP6802530B2 (ja) 通信方法
WO2012043662A1 (ja) 移動通信システム、移動局装置、ホーム基地局装置及び通信方法
JP5981983B2 (ja) ホーム基地局装置
WO2011083728A1 (ja) 移動通信システム、移動局装置、位置管理装置及び移動通信方法
WO2021233555A1 (en) Apparatus, methods, and computer programs for multicast session management in 5g networks
WO2013013546A1 (zh) 分组交换移动接入网触发媒体重定向的方法及系统、mss装置、ncs装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11819924

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11819924

Country of ref document: EP

Kind code of ref document: A1