JP6829295B2 - MBMS membership management in service capability exposure function - Google Patents

Description

(Citation of related application)
The present application claims priority to US Provisional Patent Application No. 62 / 142,156 (filed April 2, 2015), the disclosure of which is hereby incorporated by reference in its entirety.

(Field of invention)
The present application relates to devices and methods for tracking devices in a group on behalf of a server. The present application also relates to devices and methods for determining active devices in a group on behalf of a server.

Generally, a service capability exposure function (SCEF) is required by a server such as a service capability server (SCS) or application server (AS) to add a device or user device (UE) to a multicast group. The device or UE may contact the mobile network operator, but the application on the device does not know if the mobile network operator is a member of the multicast group. To accommodate this, two approaches are typically adopted. In one approach, the server may unicast the message to each device and notify the multicast group. Unicast messages can carry multimedia broadcast multicast service (MBMS) details. In another approach, the device can contact the SCEF via the user plane to learn more about the group, including, for example, a multicast address and temporary mobile group identification (TMGI). However, the device does not know when to contact the SCEF and query this information.

Additional complexity also exists for the two approaches mentioned above. For example, when the SCS / AS requires the SCEF to add a member to the group, the SCEF infers that the device is joining the group. This may not be accurate, especially if the device policies and capabilities do not match those required by the server. This can occur if the device decides not to join the group or delays joining the group. Separately, the device may be part of a group, but it may still be inactive. That is, the device is not listening for multicast messages from the server.

The aforementioned approach requires the server to know the details of the MBMS underlayer transport to the device. Specifically, the device assumes that the SCS / AS is aware of the specific details of the MBMS device context, such as the multicast address, TMGI, and so on. SCS / AS, on the other hand, assumes that there is an application on the device that listens for unicast messages from SCS / AS to join the MBMS group. Transport details deviate from the desired purpose of hiding lower group delivery and transport details from the server.

This overview is provided to introduce a series of overviews in a simplified form, further described below in the form for carrying out the invention. This summary is not intended to limit the scope of the claimed subject matter. The aforementioned needs are largely met by this application, which covers processes and systems for managing membership of devices on networks.

In one aspect of the application, computer mounting devices on a network are described. The device includes non-transient memory containing executable instructions for forming group membership. The device also includes a processor operably coupled to memory. The processor is configured to receive a request from the server to add the device to the group. The processor is also configured to send a reply to the server that the device has been approved to join the group. The processor is also configured to receive query requests from the server. In addition, the processor checks the status of the device based on the query request.

In another aspect of the present application, a networked system including a server is described. The system also includes devices communicating with the server. The device includes non-transient memory containing executable instructions for forming group membership. The device also includes a processor operably coupled to memory. The processor is configured to receive a request from the server to add the device to the group. The processor is also configured to send a reply to the server that the device has been approved to join the group. The processor is also configured to receive query requests from the server. In addition, the processor checks the status of the device based on the query request.

Yet another aspect of the present application describes computer implementation methods for constructing group membership. The method involves receiving a request from the server to add the device to the group. The method also includes sending a reply to the server that the device has been approved to join the group. The method further includes the step of receiving a query request from the server. The method still includes the step of checking the status of the device based on the query request. The method still involves sending the status of the device to the server.

As mentioned above, certain embodiments of the present invention are outlined fairly broadly in order for a deeper understanding of the detailed description and for a deeper recognition of the contribution of the present application to the art. Was done.

To facilitate a firmer understanding of the present application, reference is made herein to the accompanying drawings in which the same elements are referred to by the same number. These figures should not be construed as limiting the present application and are intended to be merely exemplary.
FIG. 1A illustrates an embodiment of a machine to machine (M2M) or IoT communication system. FIG. 1B illustrates an embodiment of the present application of the M2M service platform. FIG. 1C illustrates an embodiment of the present application in a system diagram of an exemplary M2M device. FIG. 1D illustrates an embodiment of the present application in a block diagram of an exemplary computing system. FIG. 2 illustrates a BM-SC connection to a mobile network infrastructure according to the present application. FIG. 3 illustrates a protocol for activating the MBMS multicast service according to the present application. FIG. 4 illustrates a service capability exposure architecture according to the present application. FIG. 5 illustrates an SMS service capability exposure according to the present application. FIG. 6 illustrates an architecture for group-based addressing by SCS / AS and identification of group members according to an embodiment of the present application. FIG. 7 illustrates a protocol for group-based addressing and identification of group members according to certain embodiments of the present application. FIG. 8 illustrates an MBMS-based group messaging architecture according to an embodiment of the present application. FIG. 9 illustrates a protocol for MBMS-based group messaging according to an embodiment of the present application. FIG. 10 illustrates a protocol for renewing group membership according to an embodiment of the present application. FIG. 11 illustrates a graphical user interface of a user device with respect to FIG. 10 according to an embodiment of the present application.

The embodiments for carrying out the invention will be discussed with reference to the various figures, embodiments, and aspects herein. Although this description provides detailed examples of possible implementations, it should be understood that the details are intended to be examples and therefore do not limit the scope of this disclosure.

References herein such as "one embodiment", "an embodiment", "one or more embodiments", "an aspect", etc., are specific features, structures, or references described in connection with an embodiment. It is meant that the property is included in at least one embodiment of the present disclosure. Moreover, the term "embodiment" at various locations throughout the specification does not necessarily refer to the same embodiment. That is, various features that can be presented by some embodiments but not by other embodiments are described.

This application describes new techniques and systems for adding or updating devices to a group. By doing so, the SCS / AS and SCEF are authorized to join the group and are active, eg, listening devices, are authorized to join the group but have not yet been activated. For example, it can be distinguished from non-listening devices. In particular, the SCS / AS can ask the SCEF if one or more devices are activating the MBMS service to listen for multicast.

Another embodiment preferably describes an architecture and protocol in which lower layer transport details, such as MBMS transport details, are hidden from SCS / AS. By doing so, the SCS / AS can be invoked more efficiently because the task of selecting how or when the data will be delivered to the group members will be handled by the SCEF. In one embodiment, the SCEF may employ a trigger or another initiation mechanism for the authorized device to activate the MBMS service and initiate listening for a multicast address from the server by sending a request to the device. In an exemplary embodiment, the trigger can be a service advertisement.

(Acronym)
The following acronyms will be used throughout the application, as provided in Table 1 below.

The following terms will be used throughout the present application consistently with their conventional and conventional definitions as provided in the art provided below, unless otherwise explicitly stated. Let's go.

(platform)
This application is intended to cover platform functionality and support for both application-enabled platforms (AEP) and connected device platforms (CDP). AEP includes application-enabled and service layers, including the World Wide Web and the Internet. Application-enabled layers include, but are not limited to, (i) servicing APIs, rules / scripting engines, (ii) SDK programming interfaces, and (iii) corporate system integration. The application-aware layer may also include value-added services, including, but not limited to, discovery, analysis, context, and events. Service layers, including the Worldwide Web and the Internet, include, for example, analytics, billing, low-level APIs, web service interfaces, semantic data models, device / service discovery, device management, security, data collection, data adaptation, aggregation, event management. , Context management, optimized connectivity and transport, M2M gateway, and address and identification. CDP can include connectivity analysis, usage analysis / reports / alerts, policy control, automated provisioning, SIM activation / deactivation, and subscription activation / deactivation.

(General architecture)
FIG. 1A is a schematic representation of an exemplary Machine to Machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system 10 in which one or more disclosed embodiments may be implemented. In general, M2M technology provides a building block for IoT / WoT, and any M2M device, gateway, or service platform can be an IoT / WoT component and an IoT / WoT service layer.

As shown in FIG. 1A, the M2M / IoT / WoT communication system 10 includes a communication network 12. The communication network 12 can be a fixed network such as Ethernet, Fiber, PLC, ISDN or the like, or a wireless network such as WLAN, cellular or the like, or a network of heterogeneous networks. For example, the communication network 12 may consist of a plurality of access networks that provide content such as voice, data, video, messaging, and broadcast to a plurality of users. For example, the communication network 12 is one of code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), and the like. The above channel access method can be adopted. Further, the communication network 12 may include other networks such as, for example, a core network, the Internet, a sensor network, an industrial control network, a personal area network, a fusion personal network, a satellite network, a home network, or a corporate network.

As shown in FIG. 1A, the M2M / IoT / WoT communication system 10 may include an infrastructure domain and a field domain. The infrastructure domain refers to the network side of the end-to-end M2M deployment, and the field domain usually refers to the area network behind the M2M gateway. The field domain includes an M2M gateway 14 such as an SCS with a proxy and a terminal device 18 such as a UE device. It will be appreciated that any number of M2M gateway devices 14 and M2M terminal devices 18 may be included in the M2M / IoT / WoT communication system 10 if desired. Each of the M2M gateway device 14 and the M2M terminal device 18 is configured to transmit and receive signals via a communication network 12 or a direct wireless link. The M2M gateway device 14 allows wireless M2M devices (eg, cellular and non-cellular) and fixed network M2M devices (eg, PLC) to communicate either through an operator network such as the communication network 12 or directly through a wireless link. Make it possible. For example, the M2M device 18 may collect data and transmit the data to the M2M application 20 or M2M device 18 via a communication network 12 or a direct wireless link. The M2M device 18 may also receive data from the M2M application 20 or the M2M device 18. In addition, data and signals can be transmitted to and received from the M2M application 20 via the M2M layer 22, as described below. In one embodiment, the service layer 22 can be a service capability server or an application server. The M2M device 18 and gateway 14 may communicate over a variety of networks, including cellular, WLAN, WPAN, such as Zigbee®, 6LoWPAN, Bluetooth®, direct wireless links, and wired.

Referring to FIG. 1B, the illustrated M2M service layer 22 in the field domain provides services for the M2M application 20, the M2M gateway device 14, the M2M terminal device 18, and the communication network 12. It will be appreciated that the M2M service layer 22 can communicate with any number of M2M applications, M2M gateway devices 14, M2M terminal devices 18, and communication networks 12, if desired. The M2M service layer 22 may be implemented by one or more servers, computers, and the like. The M2M service layer 22 provides service capabilities applied to the M2M terminal device 18, the M2M gateway device 14, and the M2M application 20. The functionality of the M2M service layer 22 can be implemented in various ways. For example, the M2M service layer 22 can be implemented in a web server, a cellular core network, a cloud, or the like.

Similar to the illustrated M2M service layer 22, there is an M2M service layer 22'in the infrastructure domain. The M2M service layer 22'provides services for the M2M application 20'and the underlying communication network 12'in the infrastructure domain. The M2M service layer 22'also provides services for the M2M gateway device 14 and the M2M terminal device 18 within the field domain. It will be appreciated that the M2M service layer 22'can communicate with any number of M2M applications, M2M gateway devices, and M2M terminal devices. The M2M service layer 22'can interact with service layers from different service providers. The M2M service layer 22'can be implemented by one or more servers, computers, virtual machines (eg, cloud / compute / storage farm, etc.) and the like.

Further referring to FIG. 1B, the M2M service layers 22 and 22'provide a core set of service delivery capabilities that can be utilized by a variety of applications and verticals. These service capabilities allow M2M applications 20 and 20'to interact with devices to perform functions such as data collection, data analysis, device management, security, billing, and service / device discovery. In essence, these service capabilities remove the burden of implementing these functionality from the application, thus simplifying application development and reducing the cost and time to market. Service layers 22 and 22'also allow M2M applications 20 and 20'to communicate through various networks 12 and 12'in connection with the services provided by service layers 22 and 22'.

M2M applications 20 and 20'can include applications in various industries such as, but not limited to, transportation, health and welfare, connected homes, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M service layer that boots across devices, gateways, and servers in other systems includes, for example, data collection, device management, security, billing, location tracking / geofencing, device / service discovery, And support functions such as integration of conventional systems and provide these functions as services to M2M applications 20 and 20'. In addition, the M2M service layer can also be configured to interface with other devices such as UE, SCS, and MME, as discussed in this application and illustrated in the figure.

The service layer is a software middleware layer that supports value-added service capabilities through a set of application programming interface (API) and lower layer networking interface. Both ETSI M2M and oneM2M use a service layer that may include a way for the UE to control and coordinate PSM modes. The service layer of ETSI M2M is referred to as the service capability layer (SCL). The SCL is implemented within an M2M device (referred to as device SCL (DSCL)), gateway (referred to as gateway SCL (GSCL)), and / or network node (referred to as network SCL (NSCL)). obtain. The oneM2M service layer supports a set of common service functions (CSF) (eg, service capabilities). The instantiation of one or more specific types of CSF pairs can be a common service entity (CSE) such as SCS that can be hosted on different types of network nodes, such as infrastructure nodes, middle nodes, purpose-built nodes, and so on. ). In addition, methods as described herein can be implemented as part of an M2M network that uses a service-oriented architecture (SOA) and / or a resource-oriented architecture (ROA).

FIG. 1C is a system diagram of an exemplary M2M device 30 such as, for example, an M2M terminal device 18 or an M2M gateway device 14. As shown in FIG. 1C, the M2M device 30 includes a processor 32, a transmitter / receiver 34, a transmission / reception element 36, a speaker / microphone 38, a keypad 40, a display / touchpad / indicator 42, and the like. It may include a removable memory 44, a removable memory 46, a power supply 48, a global positioning system (GPS) chipset 50, and other peripherals 52. The display 42 may also include a graphical user interface (GUI) that displays the requirements for the user equipment. This is shown, for example, in FIG. It will be appreciated that the M2M device 40 may include any subcombination of the aforementioned elements while remaining consistent with the embodiment. The device can be a device that uses the disclosed systems and methods for embedded semantic naming of sensor data. The M2M device 30 can also be employed with other devices, including, for example, UEs, routers, gateways, and servers, as described herein and illustrated in the figure.

The processor 32 is a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, and an application specific integrated circuit (SP). It can be an ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. The processor 32 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that allows the M2M device 30 to operate in a wireless environment. The processor 32 may be coupled to a transmitter / receiver 34 which may be coupled to the transmission / reception element 36. Although FIG. 1C depicts the processor 32 and the transmitter / receiver 34 as separate components, it will be appreciated that the processor 32 and the transmitter / receiver 34 can be integrated together in an electronic package or chip. The processor 32 may perform application layer programs (eg, browsers) and / or wireless access layer (RAN) programs and / or communications. The processor 32 can perform security operations such as authentication, security key matching, and / or encryption operations at the access layer and / or application layer and the like.

The transmission / reception element 36 may be configured to transmit the signal to or receive the signal from the M2M service platform 22. For example, in embodiments, the transmit / receive element 36 can be an antenna configured to transmit and / or receive RF signals. The transmission / reception element 36 may support various networks such as WLAN, WPAN, cellular and air interfaces. In embodiments, the transmit / receive element 36 can be, for example, an emitter / detector configured to transmit and / or receive an IR, UV, or visible light signal. In yet another embodiment, the transmit / receive element 36 may be configured to transmit and receive both RF and optical signals. It will be appreciated that the transmit / receive element 36 may be configured to transmit and / or receive any combination of wireless or wired signals.

In addition, although the transmit / receive element 36 is depicted in FIG. 1C as a single element, the M2M device 30 may include any number of transmit / receive elements 36. More specifically, the M2M device 30 may employ MIMO technology. Thus, in embodiments, the M2M device 30 may include two or more transmission / reception elements 36 (eg, a plurality of antennas) for transmitting and receiving radio signals.

The transmitter / receiver 34 may be configured to modulate the signal transmitted by the transmit / receive element 36 and demodulate the signal received by the transmit / receive element 36. As mentioned above, the M2M device 30 may have multimode capability. Thus, the transmitter / receiver 34 may include a plurality of transmitters / receivers to allow the M2M device 30 to communicate via a plurality of RATs such as UTRA and 802.11.

The processor 32 may access information from any type of suitable memory, such as non-removable memory 44 and / or removable memory 46, and store data therein. The non-removable memory 44 may include random access memory (RAM), read-only memory (ROM), hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identification module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In another embodiment, the processor 32 may access information from memory that is not physically located on the M2M device 30, such as on a server or home computer, and store data in it.

The processor 32 may be configured to receive power from the power source 48 and distribute and / or control power to other components within the M2M device 30. The power supply 48 can be any suitable device for powering the M2M device 30. For example, the power supply 48 includes one or more dry cell batteries (for example, nickel cadmium (NiCd), nickel zinc (NiZn), nickel hydrogen (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and the like. Can include.

The processor 32 may also be coupled to a GPS chipset 50 configured to provide location information (eg, longitude and latitude) about the current location of the M2M device 30. It will be appreciated that the M2M device 30 can acquire location information via any suitable location determination method while remaining consistent with the embodiment.

The processor 32 may also be coupled to other peripherals 52 that may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripheral device 52 includes an accelerometer, an e-compass, a satellite transmitter / receiver, a sensor, a digital camera (for photos or videos), a universal serial bus (USB) port, a vibrating device, a television transmitter / receiver, a hands-free headset, and Bluetooth. It may include modules (registered trademarks), frequency modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, and the like.

FIG. 1D is a block diagram of an exemplary computer system 90 in which, for example, the M2M service platform 22 of FIGS. 1A and 1B can be implemented. The computer system 90 may include a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software, such software being stored or accessed anywhere or by any means. Such computer-readable instructions may be executed within the central processing unit (CPU) 91 to activate the computer system 90. In many known workstations, servers, and peripheral computers, the central processing unit 91 is implemented by a single-chip CPU called a microprocessor. On other machines, the central processing unit 91 may include multiple processors. The coprocessor 81 is an optional processor that is distinctly different from the main CPU 91 and serves additional functions or assists the CPU 91. The CPU 91 and / or the coprocessor 81 may receive, generate, and process data related to the disclosed systems and methods for embedded semantic naming, such as querying sensor data with embedded semantics.

During operation, the CPU 91 fetches, decodes, and executes instructions and transfers information to and from other resources via the system bus 80, which is the main data transfer path of the computer. Such a system bus connects the components in the computer system 90 and defines a medium for data exchange. The system bus 80 typically includes a data line for transmitting data, an address line for transmitting addresses, and a control line for transmitting interrupts and operating the system bus. An embodiment of such a system bus 80 is a PCI (peripheral component interconnect) bus.

The memory device coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes circuits that allow information to be stored and retrieved. The ROM 93 generally contains stored data that cannot be easily modified. The data stored in the RAM 82 can be read or modified by the CPU 91 or other hardware device. Access to the RAM 82 and / or the ROM 93 can be controlled by the memory controller 92. The memory controller 92 may provide an address translation function that translates a virtual address into a physical address when an instruction is executed. The memory controller 92 may also provide a memory protection function that isolates the processes in the system and isolates the system processes from the user processes. Therefore, a program running in the first mode can only access the memory mapped by its own process virtual address space, and unless memory sharing between processes is set up, the virtual address space of another process. Unable to access the memory inside.

In addition, the computer system 90 may include a peripheral device controller 83 responsible for transmitting instructions from the CPU 91 to peripheral devices such as a printer 94, a keyboard 84, a mouse 95, and a disk drive 85.

The display 86, controlled by the display controller 96, is used to display the visual output produced by the computer system 90. Such visual output may include text, graphics, video graphics, and video. The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes electronic components required to generate a video signal transmitted to the display 86. The display 86 may use built-in semantics to display sensor data in a file or folder. The display 86 may also display, for example, a graphical user interface as shown in FIG. Further, the computer system 90 may include a network adapter 97 that can be used to connect the computer system 90 to an external communication network such as the network 12 of FIGS. 1A and 1B.

(General IP multicast (IPv4 and IPv6))
According to another embodiment, the IP multicast address allows a single sender to send the same data to multiple listeners. For example, a transmitting side such as SCS / AS or SCEF transmits data to a multicast IP address, and all listeners receive on the same multicast address. One feature of IP multicast groups is that addresses can be shared. Another feature is that many sources can send information to the same address. In an exemplary embodiment, the stream or channel can be multiplexed with different UDP port numbers, and each multicast listener can extract the desired information.

(Internet Group Management Protocol (IGMP))
IGMP is defined in IETF FC 3376, Internet Group Management Protocol, Version 3, and is incorporated by reference. In general, IGMP is a communication protocol used by hosts and neighboring routers on IP networks to establish multicast group membership. It is used in IPv4 systems to report their IP multicast membership to neighboring routers. Systems that support IGMP apply APIs that allow an application to communicate to the system the multicast address it wants to listen to and the network it interfaces with, such as cellular, Wi-Fi, Ethernet, etc. Expose to.

In addition, IGMP supports source filtering. This is the ability to report that a system is interested in receiving packets sent to a particular multicast address from a particular source address "only" or "other than" a particular source address. The device can also specify a filter when the application on the device indicates a multicast address that it wants to listen to.

In addition, there are two important types of IGMP messages: membership reports and membership queries. Membership reports are used by IP systems to report multicast groups of interest to neighboring routers. Membership queries are sent by IP multicast routers to query the multicast reception status of neighboring interfaces. Three types of query messages are adopted. The first type is a general query, which is sent by a router to know the full multicast receive status on all of its neighbor interfaces. In other words, it is for knowing which multicast message should be sent on each interface. The second type is a group-specific query, which is sent by a router to know the reception status for a particular multicast group. A third group and source specific query is sent by the router to know if any neighbor interface wants to receive packets sent to a particular group by a particular list of sources.

(Multicast Listener Discovery (MLD))
MLD is defined in IETF RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) and is incorporated herein with respect to IPv6. MLD is a component of IPv6 and is used by routers to discover multicast listeners on directly attached links. The protocol is incorporated into ICMPv6 instead of using a separate protocol. In addition, MLD is used in IPv6 systems to report its IP multicast membership to neighboring routers. Given the similarity of MLD to IGMP, any references to IGMP also apply to MLD.

(Multimedia Broadcast Multicast Service (MBMS))
The MBMS service is defined in 3GPP TS 23.246 Multicast / Multicast Service; Architecture and Fundamental Definition and is incorporated herein by reference. A high-level diagram of the MBMB architecture is shown in FIG. 2 and can also be found in EPC and 4G Packet Networks (Academic Press, 2013) by Magnus Olsson, et al., Which is also incorporated as a whole. As shown in FIG. 2, the content 210 is provided to the BM-SC220. The content is transmitted to the MBMS-GW 230 via the line SGmb215 or 2gi-mb216. Alternatively, the content is transmitted to the P-GW / S-GW 240 through the line SGi217. Communication from the MBMS-GW 225 to the UE or device 250 is described as a downlink dedicated MBMS broadcast. On the other hand, communication from the P-GW / S-GW 240 to the UE 250 is described as a bidirectional data connection.

The BM-SC is a node that controls the MBMS session. It initiates notification that the MBMS will be used to broadcast certain content and manages the functionality associated with terminals wishing to join the session. All interactions between the terminal and the BM-SC are handled via unicast. In general, MBMS services are user-aware. That is, the session is controlled on a user-by-user basis. The main functions of BM-SC include at least (i) service announcement function, (ii) key management function, and (iii) session and transmission function.

The protocol for how the UE activates MBMS is illustrated, for example, in FIG. Each of the steps is indicated by Roman numerals. In particular, step 1 describes how the UE activates its default PDN context along with SGSN and GGSN. In step 2, the UE attempts to join the MBMS service. The decision to join the group may respond to service advertisements (shown here). Advertisements can be transmitted via protocols, including, but not limited to, WAP push and SMS. Step 3-17 describes the activation process for MBMS. In particular, step 3 describes the approval request and response between GGSN and BM-SC. In step 4, the MBMB notification request is transmitted from the GGSN to the SGSN, and the response is received in consideration of it. In step 5, the SGSN sends a request for MBMS context activation to the UE. In step 6, the UE accepts the SGSN by activating the MBMS context request and information. In step 7, the SGSN may send a notification rejection request to the GGSN, a response is returned to the SGSN. According to step 8, the security function is transmitted between the UE and the SGSN. In step 9, the trace is called between the SGSN and the RAN. In step 10, the SGSN creates an MGMS context request. Step 11 involves an MBMS approval request and response between the GGSN and the BM-SC (see step 3 above). In step 12, the MBMS registration request and response are transmitted between the GGSN and the BMSC. Step 13 involves creating an MBMS contextual response transmitted from the GGSN to the SGSN. Then, according to step 14, the MBMS registration request can be sent from the SGSN to the GGSN and the response can be sent there. Step 15 involves provisioning the MBMS UE context to the RAN. The trace can be called in step 16. Finally, the UE activates the MBMS context acceptance protocol (step 17).

(SA2 AESE TR and SCEF)
The SA2 AESE TR is addressed in 3GPP TR 23.708, Architecture Enhancements for Service Exposure, which is incorporated as a whole by reference. This architecture addresses issues related to the Service Capacity Exposure Framework (SCEF). Network service exposure can be used to read information, request specific services, receive notifications, request specific parameter settings, etc., with appropriate approval. Create a "toolbox" for the ability. FIG. 4 illustrates a general architecture for SCEF. The illustration in FIG. 4 depicts SCEF450 within the trust domain 400. The trust domain 400 targets entity 410 protected by proper network domain security. All entities and interfaces within the trust domain 400 can be under the control of one mobile operator. Alternatively, the entity may be controlled by a trusted business partner who has a relationship with the mobile operator. The business partner can be another operator or a third party.

SCEF provides a means to securely expose the services and capabilities provided by the 3GPP network interface. SCEF provides a means for discovering exposed service capabilities. SCEF provides access to network capabilities through OMA, GSM® A, and possibly similar network application programming interfaces defined by other standardization bodies, such as the Network API 430. SCEF abstracts services from underlying 3GPP network interfaces and protocols.

According to certain embodiments, defining an interface allows SCEF to access services or capabilities in either new or existing 3GPP network elements within 3GPP. The choice of protocol to specify for such new 3GPP interfaces, such as DIAMETER, RESTful API, XML over HTTP, etc., is not limited, but the needs of the particular interface, the ease of exposure of the required information. Can depend on multiple factors, including. In addition, individual instances of SCEF can vary depending on the service capabilities exposed and the API features supported.

The functionality of SCEF can include one or more attributes. These may include, for example: (i) authentication and authorization, (ii) ability for external entities to discover exposed service capabilities, (iii) policy enforcement, (iv) warranty, (v). Accounting, (vi) Accounting Traffic Documentation, (vii) External Interconnections and Access Issues Related to Contact Points, (viii) Abstraction. Specifically, authentication and authorization includes API consumer identification, profile management, and ACL (access control list) management.

The policy enforcements introduced above include infrastructure policies, business policies, and application layer policies. Infrastructure policies include policies to protect platforms and networks. This may include ensuring that service nodes such as SMS-SC are not overloaded, for example. Business policies relate to the specific functionality that is exposed. This may include, for example, number portability, service routing, subscriber content, and the like. In addition, the application layer policy is primarily focused on the message payload or throughput provided by the application. This may include, for example, throttling.

Guarantee attributes may include integration with O & M systems. In addition, the guarantee attribute may include a guarantee process associated with the use of the API.

The abstraction involves hiding the underlying 3GPP network interfaces and protocols, allowing full network integration. The following features may be supported: (i) Underlayer Protocol Connectivity, Routing, and Traffic Control, (ii) Mapping Specific APIs to Appropriate Network Interfaces, and (iii) Protocol Conversion. The abstraction can be applied when the required functionality is not natively provided by the 3GPP network.

Separately, SCEF includes network APIs defined by OMA / GSM® A for various services. These services may include, but are not limited to, SMS, MMS, location, payment, third party calls, multimedia conference calls, and other IMS-based services. The list of OMA network APIs is'OMA AP
I Inventory, '3 GPPTS23.401 General Packet
Radio Service (GPRS) Enhancements for Evolved Universal Radio Access Network (E-UTRAN) Access. For any new service capability exposure, FFS splits between 3GPP and OMA / GSM® A / other standardization bodies to define new network APIs and related exposure functionality. Adopted for the work to be done.

In addition, applications running within a trusted domain may utilize only some of the functionality provided by SCEF, such as authentication and authorization. Applications operating within a trusted domain may also access network entities such as PCRF if the required 3GPP interface is made available. It can be accessed directly without having to go through SCEF.

The embodiment illustrated in FIG. 5 illustrates an SMS service capability exposure. Specifically, the third party application 510 uses the SMS oneAPI 520 to send and receive SMS messages. The SMS capability exposure 531 located within the SCEF530 provides a homogeneous interface for all applications. The SMS Abstraction 532, also located within SCEF530, supports different SMS messaging transport protocols such as SMPP, UCP, etc. The SMS abstraction 532 will manage and control all network sessions (including load control and message windowing) to each SMSC to which it connects. The SMS abstraction 532 maps a particular API to the T4 and Tsms interface 540 towards the SMS-SC / GMSC / IWMSC550.

(SA2 group-based expansion (GROUP) TR)
Group expansion is described in 3GPP TR 23.769 Group Based Enhancements and is incorporated herein by reference in its entirety. In general, an application involves a group of devices, each group involving hundreds or thousands of devices. Machine-type communication (MTC) devices can host multiple applications, each with a different group of devices. Devices that belong to a group are referred to as "group members". Group membership can be static or can evolve dynamically with the addition and / or removal of group members for the life of the group. SCS / AS can create new groups with associated group members and remove existing groups.

There can be different types of groups, including, but not limited to, those with relatively static membership and those with more dynamic membership. Some group operations require a core network node, such as an HSS or MME, to be unaware of the membership of UEs within the group. For example, membership can include group-based APN congestion, roaming status of all members of the group, and a count of devices belonging to the group within a given area. This solution uses maintaining group membership in HSS and is therefore applied by groups that have relatively static membership and require HSS and other core network nodes to be unaware of group membership. It will be possible.

In addition, SCS / AS specific groups are identified by an external group ID. The external ID of the 3GPP device that is a member of the group is combined with the external group ID of the group. Both static and dynamic binding of group members to external group IDs can be supported. The 3GPP device can host multiple applications and the identification of the 3GPP device can be combined with two or more external group IDs. This is because the SCEF service determines the internal group ID and the internal ID of the group members based on (i) the external group ID and the optional external ID provided by SCS / AS, and (ii) HSS determines the internal ID. Allows you to add to or request removal from the groups maintained by the HSS.

FIG. 6 illustrates a high level architecture in which the SCEF may include internal functionality associated with a group of users, such as a group management function (GMF). Through this internal function, the SCEF is a local copy of the combination of the internal ID (eg, IMSI) and the external ID (eg, MSISDN) of a group member with the group's internal group ID and external group ID. And other information needed for the delivery of group services can be maintained. For example, for a PLMN that supports MBMS, the SCEF650's internal GMF can maintain a TMGI allocated to the group. The mapping of the external group ID to the internal group ID and the location information of the group members can also be maintained in the GMF if required.

FIG. 7 illustrates a protocol for group-based address and group member identification. In this example, the SCEF includes an internal GMF. Each of the steps is indicated by Roman numerals. According to step 1, the SCS / AS requests support from the SCEF for the application specific group by sending a group address request message. The message may include an external group ID and may include an external ID of a device (UE) that is a member of the external group. In step 2, the SCEF exchanges the group information request / response message with the HSS to determine if the SCS / AS is authorized to send the group information request for the external group ID. The HSS maps any received group member external ID to an internal ID. The outer group ID is mapped to the inner group ID. The HSS returns the internal group ID and the internal ID (including the mapping of the external ID to the internal ID) to the SCEF when the external ID is submitted in the group information request.

According to step 3, the SCEF can use its internal GMF to maintain a local copy of the mapping of the external group ID to information such as the group member internal ID, and the internal group ID associated with the group member. In one embodiment, a local copy of the information can be maintained to reduce the impact on the core network nodes from frequent queries that are likely to return similar information already known to the SCEF. The SCEF then confirms with the SCS / AS using the group address response message (step 4).

According to step 5-8, construction blocks are provided for SCS / AS that require group members to be added or removed from the internal group maintained by the HSS. In step 5, the SCS / AS sends a group member addition / deletion request to the SCEF in order to have the additional external ID added to the external group ID. In step 6, the SCEF exchanges the group update request / response message with the HSS to determine if the SCS / AS is authorized to send the group membership request. The HSS maps the external group ID to the internal group ID and the external ID to the internal ID. HSS updates the subscription record for the device and adds it to the identified internal group. Subsequently, the local copy of the group membership information in SCEF can be updated (step 7). Finally, the SCEF confirms the group addition with the SCS / AS by using the group member addition / deletion response message (step 8).

The protocol in FIG. 7 above can have some impact on existing nodes and functionality. For example, in SCEF there are different support messages from SCS / AS as identified in the procedure flow. The SCEF interacts with the HSS to manage group membership and group member status information. In addition, SCEF maintains a mapping between group identifiers and device group membership.

In HSS, there may be an impact to support interaction with SCEF to provide information such as mapping of external ID to internal ID, mapping of external group ID to internal group ID, and the like. There can also be implications for modifying internal group membership. For UEs, there is generally no impact other than application layer specific functionality.

(MBMS message delivery solution)
The present application describes an architecture that, in one or more embodiments, can be reused for general group message delivery purposes. In one embodiment, the BM-SC allocates TMGI for a particular MBMS user service. In some applications, it is desirable for the eMBMS to support only broadcast mode. For some applications, it is also desirable that the eMBMS for EPS support only E-UTRAN and UTRAN. FIG. 8 illustrates one aspect of the group message delivery architecture. The SCEF810 is connected to the BM-SC820. The SCS / AS830 provides the SCEF810 with content to be broadcast and additional information. As shown in FIG. 8, the SCEF810 and BM-SC820 are not co-located, but rather the MB2 interface is located between them.

According to one embodiment, SCEF supports group messaging functionality in one of many ways. For example, SCEF supports receiving group message delivery requests from SCS / AS. This may include one or more of TMGI, radio frequency, geographical distribution area, distribution schedule, group message content. The SCEF may also support the ability to approve control plane requests from the SCS / AS. SCEF also supports querying the appropriate HSS. This may include determining whether the SCS / AS will be able to send group messaging requests to a particular group and request a TMGI allocation. The SCEF may also support reporting acceptance or non-acceptance of group message delivery requests to SCS / AS, protocol translation, and forwarding MBMS bearer activation requests towards BM-SC.

In addition, the SCEF may also obtain the TMGI and frequency of the MBMS bearer from the BM-SC if the TMGI and frequency are not provided by the SCS / AS. Otherwise, the SCEF may use the TMGI provided by the SCS / AS in the group message delivery request. The SCEF may also support the generation of group messaging specific CDRs containing group external identifiers and SCS identifiers and the transfer to CDF / CGF via instances of Rf / Ga. The SCEF may also support triggering session initiation procedures based on service area and RAT. When the SCS / AS provides the group message content within the group message delivery request, the SCEF may also transmit the content to the BM-SC over the MB2-U interface at the scheduled time.

The SCEF may also handle requests from the UE for TMGI, radio frequency, content description, and transmission schedules when requested by the SCS / AS within a group message delivery request. On the further side, having the SCEF handle requests from the UE for TMGI, radio frequency, content description, and transmission schedules is a means to isolate the SCS / AS from the details of content delivery via MBMS. I will provide a. This means that the SCEF must have a known identification, eg, FQDN, in the UE. In an exemplary embodiment, the delivery of large messages is provided to devices that are not power constrained. It is expected that power constrained devices may be preconfigured with TMGI, frequency, content description, transmission schedule, and any decryption key required to receive and understand group message content.

The SCEF may also support the reception of TMGI allocation requests from the SCS / AS. In addition, the SCEF may support the transfer of TMGI allocation requests to the BM-SC. In addition, the SCEF may support the reception of TMGI allocation requests from the BM-SC and the transfer of the TMGI to the SCS / AS.

FIG. 9 illustrates the distribution of TMGI by SCS / AS and the use of MBMS to deliver messages to a group of UEs. Each of the steps is indicated by Roman numerals. In this case, the operator treats the trigger / messaging as a normal MBMS user service and uses "service announcements" (SMS, WAP, HTTP) as defined in TS 23.246, prior to message delivery. , Related service information can be distributed to a specific group of devices. For example, this approach, shown in optional steps 1-7 of FIG. 9, can also be applied to provide specific groups of devices with relevant MBMS service information.

According to step 1, if the TMGI assigned for the external group ID does not exist, the SCS / AS sends a TMGI allocation request (external group ID, SCS ID) message to the SCEF. The SCEF checks that the SCS / AS is approved to request a TMGI allocation. In step 2, the SCEF determines whether the SCS / AS is authorized to request TMGI allocation for the group and read the relevant HSS memory "routing information", including the identification of the BM-SC. Sends a subscriber information request (external group ID and SCS ID) message to the HSS. In step 3, the HSS sends a subscriber information response (“routing information” including identification of the BM-SC) message.

Next, the SCEF transmits a TMGI allocation request (external group ID) to the BM-SC based on the information received from the HSS (step 4). The BM-SC allocates TMGI and determines the deadline for TMGI. The BM-SC then transmits a TMGI allocation response (TMGI, TMGI deadline, frequency, etc.) message to the SCEF (step 5). In step 6, the SCEF transfers the received TMGI, TMGI deadline, frequency, etc. to the SCS / AS. Subsequently, the SCS / AS signals the TMGI, frequency, schedule, etc. to all UEs belonging to the group (step 7).

After that, the SCS / AS transmits a group messaging request (external group identifier, SCS identifier, application layer content of the group message, location / area information, RAT information, TMGI) message to the SCEF (step 8). The SCS / AS may determine the IP address / port of the SCEF by making a DNS query using an external group identifier or a locally configured SCEF identifier / address. The location / area information indicated by SCS / AS can be geographic area information.

Subsequently, in step 9, the SCEF checks that the SCS / AS is authorized to send the group messaging request. The SCEF may send a subscriber information request (external group identifier and SCS identifier) message to the HSS / HLR to determine if SCS / AS is authorized to send group messaging to a particular group (external group identifier and SCS identifier). Step 10). After that, the HSS / HLR sends a subscriber information response (delivery method, cause) message. The HSS / HLR may indicate a group messaging delivery method, such as MBMS, based on subscription and / or policy (step 11). If the cause value indicates that SCS / AS is not allowed to send group messaging requests to this group, or if there is no valid subscription information, SCEF will send a group messaging confirmation message to indicate the reason for the failure condition. Sent with the cause value and the flow stops at this step. Otherwise, this flow proceeds to step 5.

According to step 12, the SCEF selects MBMS delivery based on the reception of TMGI in step 8. The SCEF sends a group messaging confirmation message to the SCS / AS to confirm that the request has been accepted for delivery to the UE (step 13). When configured as such, the UE obtains MBMS bearer parameters from the SCEF using, for example, a known address such as FQDN for the SCEF (step 14). This can result in a significant period of time prior to the actual broadcast transmission of group content.

Next, when the MBMS delivery method is selected, the SCEF sends an MBMS bearer activation request (MBMS service area, TMGI) message to the BM-SC / MBMS-GW. MBMS-GW performs a session start procedure with MME / SGSN (step 15). The MBMS-GW then performs a session start procedure with the MME / SGSN (step 16). The BM-SC then sends an MBMS bearer activation response to the SCEF (step 17). Here, the SCEF maps between the location / area information provided by the SCS / AS and the MBMS service area for distribution of group messages, based on the configuration within the operator domain. In addition, the SCEF recognizes that the selected MBMS service area can result in a message broadcast over an area larger than the area that can be indicated by the SCS / AS. This is because MBMS broadcasts at the cell particle size level are not supported.

In step 18, the SCEF transfers the group message content to the BM-SC / MBMS-GW. The group message content is delivered to the UE. In response to the received message, the UE takes a specific action considering the contents of the payload (step 19). This response typically involves the immediate or subsequent initiation of communication with the SCS / AS.

SCEF supports group messaging functionality. For example, SCEF supports receiving group messaging requests from SCS / AS. SCEF also supports the ability to approve control plane requests from SCS / AS. SCEF also supports reporting acceptance or non-acceptance of group messaging requests to SCS / AS. The SCEF also supports the provision of TMGI and radio frequencies to the SCS / AS when so required. The SCEF also supports the appropriate HSS query, for example, the SCS / AS sends a group messaging request to a particular group for TMGI allocation, or the TMGI, radio frequency, content description, and transmission schedule UE. Determine if you are allowed to provide to.

SCEF may also support protocol conversion and forwarding of group messaging requests towards BM-SC / MBMS-GW. The SCEF may also support the generation of group-specific messaging CDRs containing group external identifiers and SCS identifiers and the transfer to CDF / CGF via instances of Rf / Ga. The SCEF may also support triggering session initiation procedures based on service area and RAT. The SCEF may also support the reception of TMGI allocation requests from the SCS / AS and the transfer of the request to the BM-SC. SCEF also supports the reception of TMGI from BM-SC and the transfer of TMGI to SCS / AS.

(Adding group members)
According to a further aspect of the present application, FIG. 10 illustrates a group membership update procedure. Procedures have several advantages over existing procedures. For example, the new procedure allows SCEF to track approved devices within a group and devices participating (eg, listening) in the group. The SCS / AS indicates that the device should join the group and may require the device to be approved to join the group. When this happens, SCEF and BM-SC will record that the device can be in the group. When the SCS / AS queries the SCEF to see which devices are in the group, the SCEF is authorized to join the group and the device activating the MBMS service, or It will distinguish it from the device listening for group messages. By doing so, the SCS / AS may send the message at an opportunity.

In an exemplary embodiment, the procedure described in FIG. 10 hides all of the underlying network details from the SCS / AS. The SCS / AS does not need to contact the UE and provide the UE with a multicast address and other MBMS UE context. Instead, a trigger message from the SCEF will be sent to the UE, and the trigger payload will carry sufficient MBMS UE context information, allowing the UE to activate the service. For example, the trigger payload will carry a TMGI, APN, group name, or multicast address. The BM-SC informs the SCEF that the device is actually joining the group, for example, activating the service, so the SCEF is actually listening to the group message. You will figure out that. In turn, the SCEF will notify the SCS / AS. Alternatively, the SCEF may notify the SCS / AS at predetermined intervals rather than on demand. SCS / AS can take advantage of this feature by waiting for a group message to be sent until a device listens for a group message, or a certain number or percentage of groups listen for a group message.

Each of the steps in FIG. 10 is indicated by Roman numerals. According to this aspect of the present application, the core network may include one or more of BM-SC, HSS, MBMS-GW / GGSN, and S-GW / SGSN. The core network can also be referred to as a mobile network operator. According to this embodiment, the SCEF may reside in one of the following locations discussed below. For example, the SCEF can be located on a stand-alone node. The stand-alone node can be owned by the service provider. Alternatively, the stand-alone node can be owned by a person associated with the service provider. In another embodiment, the SCEF may be located on a server such as SCS / AS. In yet another embodiment, the SCEF may be located on a node owned by the mobile network operator.

As illustrated in FIG. 10, according to step 1, the SCS / AS sends a message to the SCEF to add a particular device to the group. The group can be a pre-established group. Alternatively, this can be a new group. The group is identified by an external group ID. The device to be added is identified by an external ID. According to one embodiment, the SCS / AS may indicate that the UE wants to be notified when it activates the MBMS service. This message can be used to add multiple UEs to a group.

According to one embodiment, when the SCS / AS requires that a group be created, modified, or the message be delivered to the group, it listens before the message is sent. The percentage of groups that should be can be indicated in the SCEF. The SCEF may either buffer or retain the message until the requested number of group members listen for the multicast. When the SCEF receives a notification from the BM-SC that more members have joined the group, the SCEF listens for enough group members to deliver the message based on the message from the SCS / AS. You can decide that you are. Then, SCEF sends a message.

According to another embodiment, the time limit may be provided to the SCEF by SCS / AS. This time limit can be an indication to the SCEF that the message should be delivered after a certain amount of time, regardless of the number of group members listening for multicast.

In step 2, the SCEF sends the group information request / response message from the SCS / AS to the HSS to determine if the SCS / AS is authorized to send the group information request for the external group ID. Can be exchanged. In one embodiment, the HSS authorizes the SCS / AS to allow members to be added to or removed from the group, mapping the external group identifier to the internal group identifier and device. Renew your subscription to indicate that you are authorized to be a member of the group. Requests from SCEF may indicate that MBMS can be used for group message delivery. In an exemplary embodiment, the response from the HSS may indicate that the APN should be used for group message delivery. UEs that receive MBMS messages will use this APN to send IGMP joins and activate services.

According to step 3, the SCEF sends an MBMS approval request to the BM-SC to check that the UE is authorized to receive the MBMS data. This message is transmitted on the MB2 reference point. The MB2 reference point is described, for example, in 3GPP TS 23.468. In one embodiment, the request may include an APN received from the HSS and an internal device identifier. In another embodiment, the request may also include an instruction that the SCEF wants to be notified that a new device will activate the MBMS service. In step 4, the response is received from the BM-SC as to whether the device is authorized to receive MBMS data. In one embodiment, the BM-SC or SCEF may employ a protocol for initiating a service announcement for an MBMS service via its service announcement function. These protocols may include, for example, WAP PUSH, HTTP, SMS, and SMS-CB. Here, the SCEF may indicate to the BM-SC whether a service announcement is required.

According to step 5, SCEF confirms that the device has been approved for addition to the group. In one embodiment, the message to SCS / AS only indicates that the UE has been approved. In another embodiment, the message in step 5 includes an indication that the device is joining a group.

According to step 6, a trigger or other mechanism is employed to send the group details to the UE over the core network. Specifically, the SCEF sends an instruction to the UE that the UE should join the multicast group. The trigger will be sent to a well-known port number where the UE is expected to listen for multicast group invitations. Alternatively, the port number on which the trigger is sent may be provided by SCS / AS. This can occur in step 1 above. In one embodiment, the trigger payload may carry one or more of the following information types: APN, multicast address, and SCS-ID.

According to one embodiment, for example, the trigger may appear on the graphical user interface 1100 on the display of the UE, as shown in FIG. The display is described and illustrated above in FIGS. 1C and 1D. Specifically, the message that appears on the graphical user interface 1100 is "A request to join the multicast / broadcast group has been received from the M2M server XYZ. Do you want to join?" The message may also indicate the server that sent the invitation. The message may also request the user's permission to join or listen to multicast / broadcast. If the user selects "Yes", the user participates as discussed in detail in step 9 below.

The SCS / AS can then send a group member query to the SCEF (step 7). The request indicates an external group ID. Group member queries can occur at any time in the process of FIG. This is described herein as occurring after trigger delivery. In step 8, SCEF returns a list of devices approved to join the group. In an exemplary embodiment, the SCEF may also provide a list of devices activating the MBMS service. As shown in FIG. 10, the device approved in step 5 has not activated the MBMS service. These steps will be discussed in more detail below. Therefore, a message to the SCS / AS will indicate that the device has been approved but has not yet listened for multicast.

According to step 9, the UE processes the trigger described above according to step 6 and uses its internal protocol to check if it wants to listen for the multicast message indicated by the SCS-ID finally received from the AS / SCS. To do. The UE establishes a default bearer in the APN indicated in the trigger. This assumes that the APN connection no longer existed. The UE then sends an IGMP / MLD join request to the multicast address. That is, the UE is requesting to join the group and actively listen for multicast messages from SCA / AS or SCEF.

The MBMS-GW or GGSN then sends an MBMS approval request to the BM-SC (step 10). The BM-SC then responds to the MBMS approval request (step 11). The MBMS service is activated using the UE (step 12). These procedures are described, for example, in 3GPP TS 23.246 Multicast Broadcast / Multicast Service; architecture and Subroutine Description.

In step 13, the BM-SC informs the SCEF that the device has activated the MBMS service. This is a new message on the MB2 reference point. In one embodiment, the BM-SC knows that this message should be transmitted by the instructions contained in the message from the server according to step 1 to the SCEF and the instructions from the SCEF following step 3 to the BM-SC. Can be. In step 14, the SCEF acknowledges the notification from the BM-SC. Steps 13 and 14 can also be used to inform the SCEF when the UE has deactivated its MBMS bearer. This information will be used to update the status of UEs in the group that have been approved by SCEF, but have been deactivated and are not listening. This can occur as a result of the following events: An event may include, for example, when the BM-SC chooses to terminate the MBMS service. The BM-SC will notify the SCEF that the UE or group is no longer listening after or before sending a "session suspension request" or "deregistration request" to GGSN or MBMS-GW. Another event may include, for example, when the UE decides to stop listening for multicast. At this point, the UE will typically send an IGMP exit message. This will cause GGSN or MBMS-GW to send an "exit instruction" to BM-SC. The "exit instruction" will cause the BM-SC to notify the SCEF that the UE is no longer listening.

According to step 15, in one embodiment, if notification is requested in step 1, the SCEF will inform the SCS / AS that the device has activated the MBMS service. In step 16, the SCS / AS acknowledges the notification from the SCEF. Subsequently, the SCS / AS sends a group member query to the SCEF. The request indicates an external group ID (step 17). Note that this voluntary message can be used as an alternative to sending a notification to the SCS / AS each time a group member activates the MBMS service. According to step 18, SCEF returns a list of devices approved to join the group. The list may also include, in a further embodiment, a list of devices activating the MBMS service. Steps 17 and 18 are similar to some extent in steps 7 and 8 above. According to FIG. 10, the device approved in step 5 now activates the MBMS service. That is, a message to SCS / AS will indicate that the device has been approved and is listening for multicast.

According to another embodiment, after step 16 and after step 18, the SCS / AS may have a guarantee that the device is listening for multicast. The SCS / AS can use this information to help determine when multicast data should begin to be sent to the group via the SCEF.

According to another embodiment, if the UE sends an "IGMP proxy join" before the SCS / AS requires the UE to be added to the group, the BM-SC will be MBMS service active for the UE. Will not approve the proxy. In this case, the BM-SC may send a request to the SCEF indicating that the UE wants to join the group. The SCEF may send a request to the SCS / AS that controls the group to see if the UE should be allowed to join the group. The SCS / AS may respond to the SCEF with instructions on whether the UE should be allowed to join the group. In turn, the SCEF may respond to the BM-SC with instructions on whether the UE is allowed to join the group. The BM-SC may use the instructions to determine if the UE should be approved for MBMS service.

According to yet another embodiment, the UE may have an application that receives the trigger shown in step 6 of FIG. This can be a well-known port provided where the UE will be listening for MBMS advertisements. When the application receives the trigger request, it may use the contents of the trigger payload to open a connection to the APN, build an IGMP join message, and then send an IGMP / MLD join message. The APN, multicast address, and multicast source address can be obtained from the trigger payload. In an alternative embodiment, the UE application may obtain the application identifier from the trigger payload and pass the APN, multicast address, and multicast source address to the second application. The second application can then guarantee the IGMP / MLD participation message. The IGMP participation operation can be an IP Multistatic Listen as described in IETF RFC 3376, Internet Group Management Protocol Version 3 and incorporated as a whole by reference. In addition, the MLD participation operation can be IPv6 Multicast Listen as described and incorporated by reference in IETF RFC 3810, Multicast Listener Discovery Version 2, (MLDv2) for IPv6.

According to the present application, any or all of the systems, methods, and processes described herein are independent, wherein the instructions include a computer, server, M2M terminal device, or UE, M2M gateway device, or SCEF. Computer-executable instructions stored on a computer-readable storage medium that perform and / or implement the systems, methods, and processes described herein when executed by a machine such as a type node. For example, it is understood that it can be embodied in the form of program code). Specifically, any of the steps, actions, or functions described above may be implemented in the form of such computer executable instructions. Computer-readable storage media include both volatile and non-volatile, removable and non-removable media, implemented by any method or technique for storing information, such computer-readable media. The storage medium does not contain a signal. Computer-readable storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage device, magnetic cassette, magnetic tape, magnetic disk storage. It includes, but is not limited to, a device or other magnetic storage device, or any other physical medium that can be used to store the desired information and is accessible by a computer.

Yet another aspect of the present application discloses a non-transient computer-readable or executable storage medium for storing computer-readable or executable instructions. The medium may include one or more computer executable instructions as disclosed above in multiple call flows according to FIGS. 3 and 7-10. Computer-executable instructions can be stored in memory, executed by a processor, and employed within the device, including the UE, SCEF, SCS / AS, and core network, disclosed in FIGS. 1C and 1D above. In one embodiment, a computer-mounted SCEF is disclosed in FIGS. 1C and 1D, having a non-volatile memory and a processor operably coupled thereto, as described above. Specifically, the non-volatile memory has instructions stored on it to distribute control and coordination of membership to the group receiving the multicast message. The processor (i) receives a request from the server to add the device to the group, (ii) sends a reply to the server that the device has been approved to join the group, and (iii) the device groups. Received a notification of joining the server, (iv) received a query request from the server, (v) checked the status of the device based on the query request, and (vi) joined the server that the device joined the group. It is configured to give an instruction that provides instructions for.

Although the systems and methods are described with respect to what is currently considered specific aspects, the present application need not be limited to the disclosed aspects. It is intended to cover the various modifications and similar sequences contained within the spirit and scope of the claims, the scope of which should be given the broadest interpretation to include all such modifications and similar structures. Is. This disclosure includes all aspects of the following claims.

Claims (11)

A device on a network, said device
Non-transient memory containing executable instructions to configure group membership,
With a processor operably coupled to said non-transient memory
The processor
Receiving a request from the server to add the device to the group
And transmitting a reply that that the device to participate in the group has been approved to the server,
When the predetermined condition is satisfied, the message received from the server is delivered to the device, and the predetermined condition is the percentage or number of devices listened to in the group, and the set time has elapsed. And that it is composed of any or a combination of them.
A device that is configured to do. The processor
Receiving a query request from the server
Checking the status of the device based on the query request
The apparatus according to claim 1, further configured to perform the above. The device of claim 2 , wherein the processor is further configured to receive said status of said device that said device is active via a core network. The device of claim 1, wherein the processor is further configured to transmit a trigger with information about broadcast or multicast communication to the device. It said information access point name, multicast address, group name, TMGI, SCS-ID, and Ru are selected from combinations thereof, according to claim 4. The device of claim 2 , wherein the status of the device is selected from joined, active, approved, and combinations thereof. The query request includes all devices that have been approved to join the group, according to claim 2. It is a networked system, and the system is
With the server
It is equipped with a device that communicates with the server.
The device
Non-transient memory containing executable instructions to configure group membership,
Including a processor operably coupled to said non-transient memory
The processor
Receiving a request from the server to add the device to the group
And transmitting a reply that that the device to participate in the group has been approved to the server,
When a predetermined condition is met, the message received from the server is delivered to the device, and the predetermined condition is the percentage or number of devices listened to in the group, and the set time has elapsed. And that it is composed of any or a combination of them.
A system that is configured to do. The system according to claim 8, wherein the system includes a service capability exposure function. The processor is further configured to receive the device status that the device is active over the core network.
The core network comprises one or more of a broadcast multimedia service center, an MBMS gateway, a gateway GPRS support node, a home subscriber server, a serving gateway, a packet data network gateway, and a serving GPRS support node. The system according to 9 . A method of constructing membership in a group.
Receiving a request from the server to add the device to the group
And transmitting a reply that that the device to participate in the group has been approved to the server,
When the predetermined condition is satisfied, the message received from the server is delivered to the device, and the predetermined condition is the percentage or number of devices listened to in the group, and the set time has elapsed. And that it is composed of any or a combination of them.
Including methods.

Images