WO2016188345A1 - Method and device for managing terminal - Google Patents

Abstract

Embodiments of the present application relate to the technical field of radio communication and specifically relate to a method and device for managing a terminal, used for solving the problem found in the prior art in which the load of a core network and the probability of a signaling storm increase as the number of machine-type terminals increases. In the embodiments of the present application, a DSC functional entity manages EPs in a cluster upon determining that authorization from a core network is acquired, where the DSC functional entity is connected to each EP in the corresponding cluster. The EPs in the cluster are managed by the DSC functional entity, the load of the core network is not increased even as the number of machine-type terminals increases, thus preventing a signaling storm caused by an excessive load on the core network.

Description

Method and device for managing terminal

The present application claims priority to Chinese Patent Application No. 201510275195.5, entitled "A Method and Apparatus for Managing Terminals", filed on May 26, 2015, the entire contents of which are incorporated by reference. In this application.

Technical field

The present application relates to the field of wireless communications technologies, and in particular, to a method and device for managing a terminal.

Background technique

Bluetooth technology is currently widely used in short-range communications, such as sensor networks.

As shown in FIG. 1A, a cluster head and a series of end nodes (EndPoint) in the Bluetooth system of the MESH (self-organizing or non-fixed infrastructure) network model form a cluster, and the EndPoint communication in the cluster is controlled by the cluster head device. The intra-cluster communication uses the 2.4 GHz common frequency band to avoid interference by frequency hopping. Statically configured channel and security parameters are used between the cluster head and the EndPoint. Each cluster is independent of each other, and EndPoint members between different clusters cannot communicate with each other.

As shown in FIG. 1B, in the existing cellular system, the terminal determines the service base station according to the strength of the downlink pilot signal, and the service base station is responsible for providing the data transmission service for the access terminal. The service base station forwards the uplink data received by the terminal to the core network, and the core network is responsible for providing the access terminal with the connection service to the external network.

In the prior art, the terminal completes the registration process to the network through an attach procedure. In the process of registering with the network, the Mobility Management Entity (MME) in the core network is responsible for saving the state information of the terminal, including security context information, activation session information, location area information, and the like. The status information of the terminal is stored in the core network, so if the access terminal is a machine type terminal, there are two problems. First of all, because the number of machine types in the future will far exceed the existing terminals (it is predicted that it may reach 50 billion to 100 billion), if the context is to be established for each machine type terminal in the core network, the core network storage will be overwhelmed. The problem. In addition, the connection management function of the existing terminal also involves the core network, which means that each time the terminal enters the connection state, a large amount of signaling to the core network is generated, and the machine type terminal is likely to cause a signaling storm after accessing the network in a large amount.

In summary, as the number of terminals of the machine type increases, the burden on the core network is increased and the signaling storm is easily caused.

Summary of the invention

The present invention provides a method and a device for managing a terminal, which solves the problem that the number of terminals of the machine type increases in the prior art, which increases the burden on the core network and easily causes a signaling storm.

A method for managing a terminal provided by an embodiment of the present application, the method includes:

The DSC functional entity determines to obtain the core network authorization;

The DSC functional entity manages EPs in the cluster, wherein the DSC functional entities are connected to each EP in the corresponding cluster.

Optionally, the DSC function entity manages the EPs in the cluster, including:

The DSC function entity authenticates the EP when the EP performs an attach process, and establishes context information of the EP after the verification is passed.

Optionally, after the verification, the DSC functional entity further includes:

The DSC function entity notifies the core network to update the corresponding cluster information.

Optionally, before the performing the attach process, the DSC function entity further includes:

The DSC function entity broadcasts the access configuration information through an air interface.

Optionally, the DSC function entity manages the EPs in the cluster, including:

The DSC function entity deletes context information of the EP in the EP detach process.

Optionally, the method further includes:

After the EP detachment is completed, the DSC function entity notifies the core network to update the corresponding cluster information.

Optionally, the DSC function entity manages the EPs in the cluster, including:

After receiving the status update request of the EP, the DSC function entity updates the context information of the EP, and notifies the core network to update the corresponding cluster information.

Optionally, the DSC function entity manages the EPs in the cluster, including:

Determining, by the DSC function entity, the service requested by the EP according to the received service identifier or terminal type information from the EP;

The DSC function entity saves the EP activation service information into the context information of the EP after the service requested by the EP is authorized.

Optionally, the DSC function entity determines, according to the received service identifier or terminal type information from the EP, the service that the EP requests to activate, and further includes:

After the service requested by the EP request is not activated, the DSC function entity initiates a service authorization request process to the core network;

The DSC function entity saves the EP activation service information to the context information of the EP after determining that the service requested by the EP request has been authorized according to the indication of the core network.

Optionally, the DSC function entity manages the EPs in the cluster, including:

The DSC function entity updates the activation service information saved in the context information of the EP after the EP requests to deactivate the service.

Optionally, after the EP requests to deactivate the service, the DSC function entity further includes:

After determining that the authorized service needs to be updated, the DSC function entity notifies the core network to update the authorized service.

Optionally, the DSC function entity manages the EPs in the cluster, including:

After the core network notifies that the authorized service needs to be updated, the DSC function entity updates the authorized service of the corresponding cluster.

Optionally, after updating the authorization service of the corresponding cluster, the DSC function entity further includes:

The DSC function entity notifies the EP that needs to be deactivated to perform the deactivation operation, and updates the activation service information in the context information of the EP of the deactivation operation, after determining that the EP needs to be deactivated according to the updated authorization service.

Optionally, the DSC functional entity is a mobile terminal or base station type device or a server type device or a distributed service center; and/or

The EP is a mobile terminal or a wearable device or a machine type device.

Another method for managing a terminal provided by the embodiment of the present application includes:

The core network device determines the DSC functional entity that needs to be authorized;

The core network device authorizes the determined DSC functional entity to enable the DSC functional entity to manage the EPs in the cluster, wherein the DSC functional entity is connected to each EP in the corresponding cluster.

Optionally, after the core network device authorizes the determined DSC function entity, the method further includes:

The core network device updates the cluster information corresponding to the DSC functional entity according to the cluster information notified by the received DSC function entity.

A DSC functional entity for managing a terminal, where the DSC functional entity includes:

a first determining module, configured to determine to obtain a core network authorization;

A management module is configured to manage EPs in the cluster, wherein the DSC functional entity is connected to each EP in the corresponding cluster.

Optionally, the management module is specifically configured to perform identity verification on the EP when the EP performs an attach process, and establish context information of the EP after the verification is passed.

Optionally, the management module is further configured to: after the verification is passed, notify the core network to update the corresponding cluster information.

Optionally, the management module is further configured to: before the EP performs an attach process, broadcast the access configuration information by using an air interface.

Optionally, the management module is specifically configured to: delete the context information of the EP in the EP detach process.

Optionally, the management module is further configured to notify the core network to update the corresponding cluster information after the EP detachment is completed.

Optionally, the management module is specifically configured to: after receiving the status update request of the EP, update context information of the EP, and notify the core network to update corresponding cluster information.

Optionally, the management module is specifically configured to: according to the received service identifier or terminal type information from the EP, Determining the service that the EP requests to be activated; after the service requested by the EP request has been authorized, saving the EP activation service information into the context information of the EP.

Optionally, the management module is further configured to: after the service requested by the EP request is not activated, initiate a service authorization request process to the core network; and determine, according to the indication of the core network, the service that is activated by the EP request After the authorization has been granted, the EP activation service information is saved in the context information of the EP.

Optionally, the management module is specifically configured to: after the EP requests to deactivate the service, update the activated service information saved in the context information of the EP.

Optionally, the management module is further configured to notify the core network to update the authorized service after determining that the authorized service needs to be updated.

Optionally, the management module is specifically configured to: after the core network notifies that the authorized service needs to be updated, update the authorized service of the corresponding cluster.

Optionally, the management module is further configured to: after updating the authorized service of the corresponding cluster, according to the updated authorized service, after determining that the EP needs to be deactivated, notify the EP that needs to be deactivated to perform the deactivation operation, And the activation service information in the context information of the EP of the deactivation operation is updated.

Optionally, the DSC functional entity is a mobile terminal or base station type device or a server type device or a distributed service center; and/or

The EP is a mobile terminal or a wearable device or a machine type device.

A core network device for managing a terminal, where the core network device includes:

a second determining module, configured to determine a DSC functional entity that needs to be authorized;

And a processing module, configured to authorize the determined DSC function entity, so that the DSC function entity manages the EPs in the cluster, where the DSC function entity is connected to each EP in the corresponding cluster.

Optionally, the processing module is further configured to: after authorizing the determined DSC function entity, update the cluster information corresponding to the DSC function entity according to the cluster information notified by the received DSC function entity.

In the embodiment of the present application, after determining that the core network is authorized, the DSC function entity manages the EPs in the cluster, where the DSC function entity is connected to each EP in the corresponding cluster. Since the EPs in the cluster are managed by the DSC functional entity, the burden on the core network is not increased after the number of terminals of the machine type is increased, thereby avoiding the signaling storm caused by the excessive burden of the core network.

DRAWINGS

1A is a schematic structural diagram of a MESH network in the background art;

1B is a schematic structural diagram of a cellular network in the background art;

2 is a schematic structural diagram of a distributed network according to an embodiment of the present application;

FIG. 3 is a schematic structural diagram of a system for managing a terminal according to an embodiment of the present application;

4 is a schematic structural diagram of a first DSC functional entity according to an embodiment of the present application;

FIG. 5 is a schematic structural diagram of a first core network device according to an embodiment of the present application;

6 is a schematic structural diagram of a second DSC functional entity according to an embodiment of the present application;

7 is a schematic structural diagram of a second core network device according to an embodiment of the present application;

FIG. 8 is a schematic flowchart of a first method for managing a terminal according to an embodiment of the present application;

FIG. 9 is a schematic flowchart of a method for managing a terminal according to a second embodiment of the present application;

FIG. 10 is a schematic flowchart of a method for attaching a terminal according to an embodiment of the present application;

11 is a schematic flowchart of a method for triggering detachment of a terminal according to an embodiment of the present application;

FIG. 12 is a schematic flowchart of a method for triggering a status update of a terminal according to an embodiment of the present disclosure;

FIG. 13 is a schematic flowchart of a method for triggering a service activation of a terminal according to an embodiment of the present disclosure;

FIG. 14 is a schematic flowchart of a method for deactivating a terminal trigger service according to an embodiment of the present disclosure;

FIG. 15 is a schematic flowchart of a method for deactivating a trigger service of a core network according to an embodiment of the present disclosure.

detailed description

In the embodiment of the present application, after determining that the core network is authorized, the DSC function entity manages the EPs in the cluster, where the DSC function entity is connected to each EP in the corresponding cluster. Since the EPs in the cluster are managed by the DSC functional entity, the burden on the core network is not increased after the number of terminals of the machine type is increased, thereby avoiding the signaling storm caused by the excessive burden of the core network.

The clusters in the embodiments of the present application may also be referred to as groups.

The following describes the scenario in which the application of this application is applied. As shown in FIG. 2, the distributed network system in this embodiment of the present application includes: a MESH access network, a cellular access network, a backhaul network, and a core network.

The MESH access network is connected to the core network through the backhaul network; and the cellular access network is connected to the core network through the backhaul network.

The backhaul network includes a wired backhaul network, a wireless backhaul network, and a mobile cellular backhaul network.

The core network consists of various dedicated and general-purpose business units, data centers, routers, etc. It is responsible for contract management, user identity verification, authentication, policy control, billing management, and business management functions for various access devices.

The MESH access network mainly provides services for Machine Type Communication (MTC), and the EndPoint (end node) can be bound to a sensor device (for example, a temperature sensor, a pressure sensor, a camera, etc.), or Binding execution device actuators (eg, accelerators, brakes, steering gears, robotic arms, etc.) can also be bound to physical entities (eg, cars, bicycles, helmets, glasses, smart watches, unmanned aerial vehicles, etc.).

The cellular access network mainly provides access services for a traditional handheld or vehicle-mounted access device (Device) or modem (Modem), and the cellular access network can also provide signaling and data to the core network for the MESH access network. Return business.

Before introducing the specific system architecture, introduce the interfaces in the following figure:

Me1 interface: Interface established between the DSC function entity and the NSC.

Me2 interface: An interface established between a DSC functional entity and a DSC functional entity.

Me3 interface: An interface established between a DSC functional entity and an EP (EndPoint).

Me4 interface: Interface established between the EP and the EP.

C1 interface: An interface established between the LSC and the NSC.

C2 interface: An interface established between the LSC and the base station.

C3 interface: An interface established between the LSC and the access point AP.

C4 interface: Several ports established between the base station and the Device.

C5 interface: Interface established between the access point AP and the device.

C6 interface: Interface between Device and Device.

In1: Interface established between the DSC functional entity and the LSC.

In2: Interface established between the LSC and the LSC.

The MESH access network includes at least one DSC functional entity and at least one EP, the cellular access network includes at least one LSC, and further includes at least one base station and/or at least one AP, and the core network includes at least one NSC.

Each entity is described below.

1. End node EndPoint (EP):

The EP is an MTC-type access device with communication functions. By accessing the "cluster" to obtain data transmission services, it can be bound to specific physical devices, such as various sensor sensors, actuator actuators, accelerators, braking devices, robot arms, Aircraft, cars, bicycles, safety helmets, smart glasses, smart watches, etc. Depending on the specific physical device being bound, you can select an EP with different communication capabilities. A typical EP is a communication scenario that is oriented for close distances (eg, less than 100 m) and low data rates (eg, less than 1000 bits/s). The embodiment of the present application is also applicable to a long distance high rate EP.

2. Distributed Service Center Distribute ServiceCenter (DSC) functional entity:

And the DSC function entity is configured to transmit, by the backhaul network, information related to the EP in the corresponding cluster with the core network, where the DSC function entity is connected to each EP in the corresponding cluster.

In an implementation, the DSC functional entity forms a cluster with the EndPoints connected to the surrounding and DSC functional entities.

Optionally, the DSC functional entity is also responsible for managing and maintaining the cluster.

Specifically, the DSC functional entity manages the EPs in the corresponding cluster, coordinates communication with other adjacent clusters, and performs interference management.

If the MESH access network shares wireless resources with other wireless networks, the DSC functional entity may also coordinate Interference with adjacent or co-covered heterogeneous radio resource control entities, and cross-system communication with the heterogeneous system.

For example, the DSC function entity may notify the surrounding DSC function entity or LSC of the time or frequency information of the radio resource allocated for "intra-cluster communication";

Correspondingly, the surrounding DSC functional entities and LSCs avoid communicating at the same time or frequency.

The DSC functional entity may also notify the surrounding DSC functional entity or LSC of the interference information measured by the EP or the intra-cluster EP;

Correspondingly, if the surrounding DSC function entity or the LSC determines that it interferes with other clusters or "local access network" communication, the interference can be weakened by reducing the transmission power.

In terms of service layer and cluster member management: the DSC function entity is responsible for participating in the maintenance of the member list, the cluster member authentication, and the maintenance of the device type and service requirements associated with the EndPoint.

MESH access network level: The DSC functional entity acts as the control point of the cluster, and is also responsible for coordinating communication with other neighboring clusters and interference management.

In terms of cross-system coordination: For the case where the MESH access network shares radio resources with other wireless networks (such as cellular), the DSC functional entity is also responsible for coordinating interference and cross-system communication with adjacent or co-covered heterogeneous radio resource control entities. (For example, the DSC functional entity is responsible for coordinating the base station for interference coordination).

The DSC functional entity supports hardware and software decoupling and software configurability. The DSC function entity is responsible for controlling the EP type terminal access, and the DSC function entity needs to verify the terminal identity during the terminal access process. Because the core network adopts a cluster-based management policy, the DSC function entity is responsible for reporting the cluster information managed by itself to the core network, where the cluster information includes the number of members in the cluster managed by the DSC functional entity, and the activated services in the cluster managed by the DSC functional entity. Information, etc.

3. Local Service Center (LSC):

The LSC is configured to transmit, by using the backhaul network, information related to a specific access device with the core network, where the specific access device is connected to a base station connected to the LSC or AP access device.

Optionally, the LSC also performs connection management and transmission management on the specific access device.

Specifically, the transmission management includes some or all of the following management:

Perform interference management across base stations and/or across APs;

Interference coordination or radio resource coordination with cellular local access networks that are adjacent or overlapping;

Performing radio resource configuration and/or transmission parameter configuration in a multi-base station and/or multi-AP transmission mode;

Radio resource coordination is performed between adjacent or overlapping coverage MESH access networks.

For example, the LSC may notify the surrounding DSC function entity or LSC of the radio resource that allocates the "local access network" communication;

Accordingly, the surrounding DSC functional entity or LSC avoids communicating with the same time or frequency resources.

The LSC can also notify the surrounding area according to the interference information measured by the AP, the BS, and the access device in the local access network. DSC functional entity or LSC;

Correspondingly, if the surrounding DSC function entity or the LSC determines that it interferes with other clusters or "local access network" communication, the interference can be weakened by reducing the transmission power.

In an implementation, the cellular access network in the embodiment of the present application has a plurality of cellular local access networks that can overlap each other. The base stations in the cellular local access network may be various types of base stations.

The LSC and the base station or the access point AP together form a cellular local access network, wherein if the cellular local access network is formed by the LSC and the base station, it is responsible for providing wide area coverage for a specific geographical area; if the cellular local access network is operated by the LSC and When APs are formed together, they are responsible for enhancing the service for hotspot capacity. The cellular access network has a plurality of cellular local access networks that can overlap each other.

4. Base station (BS):

The base station BS and the LSC together form a cellular local access network (macro network layer), which is responsible for providing wide area coverage services for specific geographical areas. Ensure that the access device always has a seamless connection experience during the mobile process.

Specifically, the base station can perform some or all of the following functions:

Responsible for controlling the wireless access process;

Responsible for baseband processing related to physical layer wireless transmission;

For single cell transmission, perform radio resource scheduling and transmission parameter configuration;

Broadcast multicast transmission services are provided for devices under wide area coverage through a broadcast channel.

5. Access point AP:

The access point AP and the LSC together form a cellular local access network (hotspot network layer), which is responsible for providing capacity services for the hotspot area, thereby providing a higher data transmission rate for the access device. The AP itself can be seen as a low-cost base station that is tailored for functionality and hardware capabilities.

Specifically, the AP can perform some or all of the following functions:

Responsible for controlling the wireless access process.

Responsible for baseband processing related to physical layer wireless transmission.

For single cell transmission, radio resource scheduling and transmission parameter configuration are performed.

In the case of no device access, you can enter silent mode to reduce power consumption.

6, device Device:

The Device can be a terminal, a Modem device, or other device capable of accessing the network through a cellular access network.

Optionally, the Device itself may also provide a relay service to the core network or the external network for the members of the MESH access network.

Optionally, the Device in the embodiment of the present application can support access to a cellular network (for example, a linear distance of more than 1500 m from a base station antenna) at a high speed (for example, a moving speed exceeding 500 km/h), and supports a very high data transmission rate. (eg data transfer rate greater than 1Gbps).

Optionally, the device in the embodiment of the present application may receive broadcast service information by using a system broadcast channel.

Optionally, the device in the embodiment of the present application can obtain a data transmission service by accessing a cellular network.

Optionally, the device in the embodiment of the present application can implement direct communication between devices.

7. Network Service Center (NSC):

The NSC is responsible for terminating the access network to the core network control plane interface. NSC supports hardware and software decoupling and software configurability.

The NSC is configured to transmit, by using the backhaul network, information about the received DSC function entity and/or the LSC to the core network.

That is to say, in terms of connection management, the NSC is responsible for terminating the control plane connection of the MESH access network and the cellular access network to the core network.

Optionally, in terms of network layer security, the NSC is responsible for authenticating the DSC functional entity and the LSC and establishing a secure tunnel.

Specifically, the NSC may perform identity verification on the DSC functional entity and/or the LSC, and establish, after the verification, the backhaul network between the DSC functional entity and/or the LSC. A secure tunnel for transmitting data.

For example, the NSC and the DSC functional entity and the LSC implement identity authentication through a certificate mechanism, and establish an IPsec secure channel to ensure the security of the Me1 and C1 interfaces.

Optionally, the NSC may also manage the EP and the specific access device connected to the DSC functional entity in a service layer and an identity.

Optionally, it is responsible for processing control plane signaling received from the MESH access network and the cellular access network, including EP, Device identity verification, device type and service type verification and activation process associated with the EP, and Device The device activates a session to a specific external network, and so on.

For example, the NSC is responsible for managing the status information of the EP, including tracking management ("cluster" information currently accessed by the EP), session management (such as the service currently activated by the EP), and identity management (such as the device type and service type of the EP contract). .

In implementation, the NSC is a central control unit, and both the LSC and DSC functional entities belong to the distributed control unit.

Optionally, in terms of management, the LSC and DSC functional entities are responsible for controlling local and time-delayed functions. The NSC is responsible for the overall, low latency requirements and controls for high security requirements.

For example, the LSC is responsible for the management of the "cluster members" and saves the information of the current cluster members. The method includes assigning a temporary identifier to the cluster member, and is responsible for performing radio resource allocation for intra-cluster communication, and managing the air interface frame format and air interface basic parameters in the cluster.

The DSC function entity is responsible for managing the local access network, including maintaining the local access network AP, the BS list, establishing a reliable connection between the AP and the BS, and performing radio resource allocation and coordination for intra-AP communication or intra-BS communication. Responsible for link management of Devices accessed from APs and BSs. The DSC functional entity can also control AP and BS user plane data forwarding path selection, the DSC function entity can also perform AP, BS in air interface frame structure, frame configuration parameters, and AP, BS transmission scheme used at the MAC layer, and high layer protocol stack. The architecture is configured.

In implementation, the core network itself may deploy one or more NSCs, and different NSCs are equal to each other. On the access network side, due to the distributed nature of the access network, the LSC is deployed according to the geographic area and the type of coverage or capacity enhancement area. Each LSC area is controlled by one LSC, and different LSCs are also equal to each other. There is no hierarchical relationship (whether the LSC control macro base station or the LSC control access point).

Wherein, the clusters in the MESH access network can overlap each other;

The local access networks in the cellular access network can overlap each other;

The local access network and the clusters can overlap each other.

Optionally, the MESH access network and the cellular access network use a dedicated frequency of a traditional cellular or other public common frequency. For example, the traditional cellular system uses dedicated frequency, and the primary frequency is allocated to different operators for specific cellular systems, such as Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (Wide-band Code). Division Multiple Access (WCDMA), Long Term Evolution (LTE), the frequency used by TD-SCDMA Long Term Evolution (TD-LTE); the dedicated frequency used by traditional cellular systems In addition, frequency resources shared by multiple wireless communication systems of the same or different standards.

The embodiments of the present application are further described in detail below with reference to the accompanying drawings.

As shown in FIG. 3, the system for managing a terminal in this embodiment of the present application includes: a DSC functional entity 10 and a core network device 20.

The DSC function entity 10 is configured to determine to obtain the core network authorization, and manage the EPs in the cluster, where the DSC function entity is connected to each EP in the corresponding cluster.

The core network device 20 is configured to determine a DSC functional entity that needs to be authorized; and authorize the determined DSC functional entity.

In implementations, clusters of embodiments of the present application may also be referred to as groups.

The DSC functional entity of the embodiment of the present application may be a mobile terminal, such as a handheld terminal (such as a smart phone), or a base station type device (such as a micro base station) or a server type device or a distributed service center.

The EP of the embodiment of the present application may be a mobile terminal, such as a handheld terminal (such as a smart phone), or a wearable device (such as a smart bracelet), or a machine type device (such as a sensor).

The EP of the embodiment of the present application may be invisible to the core network. The core network device can perform managed management of the MTC type access terminal by authorizing the DSC functional entity. An authorized DSC functional entity can sign an agreement with an operator. In the implementation, the operator can configure the management function of the DSC functional entity through software. The DSC functional entity and the EP configured with the management function form a dynamic network through self-organizing, and are managed by the DSC functional entity. The DSC function entity reports the "group information" of the dynamic network itself or the "cluster information" as a whole to report the core network device, the core network. The device can perform charging, policy control, and other functions according to "group information" or "cluster information".

In the embodiment of the present application, when the DSC functional entity 10 manages the EP in the cluster, the security mechanism adopted between the EP and the DSC functional entity can be customized according to the needs of the user, and does not need to be contracted to the operator in advance (for example, for a factory or for In-vehicle systems can use different security mechanisms). In addition, the EP is not visible to the operator's core network, so the core network uses a cluster-based charging strategy (ie, the cluster is treated as a basic user, for example, a contracted factory is a user) instead of using traditional terminal-based charging. Strategy.

The DSC functional entity 10 manages the EPs in the cluster including but not limited to some or all of the following:

EP attach process, EP detach process, EP state update process, service activation process, service deactivation process.

The following is introduced separately.

First, the EP attachment process.

The DSC function entity authenticates the EP when the EP performs an attach process, and establishes context information of the EP after the verification is passed.

In an implementation, the DSC functional entity broadcasts the access configuration information through the air interface. Access configuration information includes but is not limited to some or all of the following information:

Network identifier, DSC function entity identifier, and service identifier list information.

After receiving the access configuration information, the EP may initiate an attach request to the DSC function entity according to the access configuration information, where the attach request may include the EP fixed identifier and the identity verification information.

After receiving the attach request, the DSC function entity determines the corresponding EP according to the fixed identifier of the EP, and authenticates the EP according to the identity verification information of the EP, and establishes the context information of the EP after the verification is passed.

In the implementation, there are many ways to perform authentication, such as verification through a security certificate mechanism.

Optionally, after the verification is passed, the DSC function entity may return an attach response message to the EP, where the temporary identifier of the EP, the fixed identifier of the EP, and the IDC function entity identity verification information may be included;

Correspondingly, after receiving the attach response, the EP verifies the validity of the network, and sends an attach complete message to the DSC function entity after the verification is passed, which may include the temporary identifier of the EP;

After receiving the attach complete message, the DSC functional entity establishes context information of the EP.

Currently, there are many technologies for terminal and network identity mutual authentication (for example, based on certificate, authentication, authorization and accounting (AAA) or authentication and key agreement (AKA), etc.). The embodiment of the present application is applicable to the current terminal and network identity mutual authentication technology, and the embodiment of the present application can also customize the security scheme adopted between the terminal EP and the DSC functional entity according to user requirements, for example, for a smart factory or an in-vehicle system, the user (factory, depot) can require their own customized security solutions.

Optionally, after the verification is passed, the DSC function entity may further notify the core network to update the corresponding cluster information.

The cluster information includes but is not limited to some or all of the following information:

The number information of the EPs in the cluster, the activation service information in the cluster, the bandwidth used by the MESH system, and the carrier frequency information used by the MESH system.

Correspondingly, the core network device updates the cluster information corresponding to the DSC functional entity according to the cluster information notified by the received DSC function entity.

Second, the EP de-attachment process.

In an implementation, the detach request message may be sent to the DSC functional entity before the EP is removed or shut down, which may include the temporary identifier of the EP.

After receiving the detach request message, the DSC function entity deletes the context information of the corresponding EP.

Optionally, after deleting the context information of the corresponding EP, the DSC function entity may further send a detachment response to the EP, where the temporary identifier of the EP may be included.

Optionally, after deleting the context information of the corresponding EP, the DSC function entity may further notify the core network to update the corresponding cluster information.

The cluster information includes but is not limited to some or all of the following information:

The number information of the EPs in the cluster, the activation service information in the cluster, the bandwidth used by the MESH system, and the carrier frequency information used by the MESH system.

Correspondingly, the core network device updates the cluster information corresponding to the DSC functional entity according to the cluster information notified by the received DSC function entity.

Third, the EP trigger status update process.

After the EP attaches to the network, the EP and DSC functional entities initiate a status update timer.

The EP sends a status update request to the DSC functional entity after the status update timer expires, wherein the status update request may include a temporary identification of the EP.

After receiving the status update request, the DSC function entity determines the corresponding EP according to the temporary identifier of the EP, and updates the context information corresponding to the EP.

After updating the context information of the EP, the DSC function entity may send a status update response to the EP, which may include a temporary identifier of the EP.

Optionally, after updating the context information of the EP, the DSC function entity may further notify the core network to update the corresponding cluster information.

The cluster information includes but is not limited to some or all of the following information:

The number information of the EPs in the cluster, the activation service information in the cluster, the bandwidth used by the MESH system, and the carrier frequency information used by the MESH system.

Correspondingly, the core network device updates the cluster information corresponding to the DSC functional entity according to the cluster information notified by the received DSC function entity.

Optionally, the DSC function entity maintains two state update timers T1 and T2 for the corresponding EP, if After the status update timer T1 expires and the status update request of the corresponding EP is not received, the DSC function entity considers that the EP is in an attach abnormal state, and releases the context information of the EP after the status update timer T2 times out.

In the implementation, if the T2 does not timeout and receives the status update request after the timeout of T1, the embodiment of the present application provides a processing manner:

Because the T1 timeout DSC function entity sets the state of the terminal to the "abnormal" state (in the abnormal state, the DSC function entity can suspend the provision of data transmission service to the terminal), after T1 times out, T2 does not timeout to receive the status update request, DSC The functional entity resets the terminal's status information to the "normal" state.

Optionally, the status update timer T2 may be started after the status update timer T1 times out. If the duration of the status update timer T2 is greater than the duration of the status update timer T1, the status update timer T2 may also be started together with the status update timer T1.

4. The EP triggers the service activation.

The EP sends a service activation request to the DSC function entity when the new service needs to be activated, where the request may include the service identifier and/or the terminal type information;

Correspondingly, the DSC function entity determines, according to the received service identifier or terminal type information from the EP, the service that the EP requests to activate;

If the service requested by the EP request has been authorized, the EP activation service information is saved in the context information of the EP.

If the service requested by the EP is not authorized, the DSC function entity may perform a service authorization request to the core network, and if the core network authorizes the service, save the EP activation service information to the context information of the EP, if the core If the network does not authorize the service, the DSC function entity will not enable related functions.

For example, the factory A user has signed a service to connect the robot using the MESH network in the factory, but in fact, the factory A uses the contract to connect the sensor in the car. In this case, the service will not be authorized by the core network.

Optionally, if the EP requests the activated service authorization, the DSC function entity may send a service activation response to the EP.

Correspondingly, after receiving the EP, the EP returns a service activation complete message to the terminal.

5. The EP triggers the service to be deactivated.

The EP sends a service deactivation request to the DSC function entity when the service needs to be deactivated, where the request may include the service identifier and/or the terminal type information;

After receiving the service deactivation request, the DSC function entity updates the activation service information saved in the context information of the EP.

Optionally, after receiving the service deactivation request, the DSC function entity may further determine whether the authorized service needs to be updated, and if necessary, notify the core network to update the authorized service.

For example, if the DSC function entity authorization list includes a video real-time backhaul service, and the DSC function entity is responsible for managing a terminal that does not activate the service, the DSC function entity may initiate a cluster (group) service authorization to the core network. The new process updates the DSC functional entity authorization service list.

Optionally, after the activation service information saved in the context information of the EP is updated, the DSC function entity may further send a service deactivation command to the EP.

Correspondingly, the EP can return a service deactivation completion message to the DSC functional entity.

6. The core network triggers the service to be deactivated.

After the core network device expires or fails to authorize some or all of the services authorized by some DSC functional entities, the core network device initiates a cluster service authorization update process to the DSC functional entity.

Correspondingly, after the core network notifies that the authorized service needs to be updated, the DSC function entity updates the authorized service of the corresponding cluster.

Optionally, if the failed service is an activated service, the activated service needs to be deactivated.

Specifically, the DSC function entity determines, after the core network needs to update the authorized service, whether to deactivate the service activated by the EP in the cluster, and if yes, sends a service deactivation command to the EP;

Correspondingly, after receiving the service deactivation command, the EP returns a service deactivation completion message.

After receiving the service deactivation completion message, the DSC function entity updates the activation service information saved in the context information of the EP.

As shown in FIG. 4, the first type of DSC function entity in the embodiment of the present application includes: a first determining module 400 and a management module 401.

a first determining module 400, configured to determine to obtain a core network authorization;

The management module 401 is configured to manage the EPs in the cluster, where the DSC functional entity is connected to each EP in the corresponding cluster.

Optionally, the management module 401 is specifically configured to perform identity verification on the EP when the EP performs an attach process, and establish context information of the EP after the verification is passed.

Optionally, the management module 401 is further configured to: after the verification is passed, notify the core network to update the corresponding cluster information.

Optionally, the management module 401 is further configured to: before the EP performs an attach process, broadcast the access configuration information by using an air interface.

Optionally, the management module 401 is specifically configured to: delete the context information of the EP in the EP detach process.

Optionally, the management module 401 is further configured to: after the EP detachment is completed, notify the core network to update the corresponding cluster information.

Optionally, the management module 401 is specifically configured to: after receiving the status update request of the EP, update the context information of the EP, and notify the core network to update the corresponding cluster information.

Optionally, the management module 401 is specifically configured to: according to the received service identifier or terminal type identifier from the EP And determining, by the EP, the activated service, and saving the EP activation service information to the context information of the EP after the service requested by the EP is authorized.

Optionally, the management module 401 is further configured to: after the service requested by the EP request is not activated, initiate a service authorization request process to the core network; and determine, according to the indication of the core network, that the EP request is activated. After the service has been authorized, the EP activation service information is saved in the context information of the EP.

Optionally, the management module 401 is specifically configured to: after the EP requests to deactivate the service, update the activated service information saved in the context information of the EP.

Optionally, the management module 401 is further configured to: after determining that the authorized service needs to be updated, notify the core network to update the authorized service.

Optionally, the management module 401 is specifically configured to: after the core network notifies that the authorized service needs to be updated, update the authorized service of the corresponding cluster.

Optionally, the management module 401 is further configured to: after updating the authorized service of the corresponding cluster, according to the updated authorized service, after determining that the EP needs to be deactivated, notify the EP that needs to be deactivated to perform the deactivation operation. And update the activation service information in the context information of the EP of the deactivation operation.

Optionally, the DSC functional entity is a mobile terminal or base station type device or a server type device or a distributed service center; and/or

The EP is a mobile terminal or a wearable device or a machine type device.

As shown in FIG. 5, the first core network device in this embodiment of the present application includes: a second determining module 500 and a processing module 501.

a second determining module 500, configured to determine a DSC functional entity that needs to be authorized;

The processing module 501 is configured to authorize the determined DSC function entity, so that the DSC function entity manages the EPs in the cluster, where the DSC function entity is connected to each EP in the corresponding cluster.

Optionally, the processing module 501 is further configured to: after authorizing the determined DSC function entity, update the cluster information corresponding to the DSC function entity according to the cluster information notified by the received DSC function entity.

As shown in FIG. 6, the second DSC functional entity in this embodiment of the present application includes:

The processor 601 is configured to read a program in the memory 604 and perform the following process:

Determining the acquisition of the core network authorization; managing the EPs in the cluster, wherein the DSC functional entity is connected to each EP in the corresponding cluster.

The transceiver 602 is configured to receive and transmit data under the control of the processor 601.

Optionally, the processor 601 is specifically configured to perform identity verification on the EP when the EP performs an attach process, and establish context information of the EP after the verification is passed.

Optionally, the processor 601 is further configured to: after the verification is passed, notify the core network to update the corresponding cluster information.

Optionally, the processor 601 is further configured to: before the EP performs an attach process, access configuration information is Broadcast through the air.

Optionally, the processor 601 is specifically configured to: delete the context information of the EP in the EP detach process.

Optionally, the processor 601 is further configured to: after the EP detaching is completed, notify the core network to update corresponding cluster information.

Optionally, the processor 601 is specifically configured to: after receiving the status update request of the EP, update context information of the EP, and notify the core network to update corresponding cluster information.

Optionally, the processor 601 is specifically configured to: determine, according to the received service identifier or terminal type information from the EP, the service that the EP requests to activate; after the service requested by the EP request has been authorized, The EP activation service information is saved in the context information of the EP.

Optionally, the processor 601 is further configured to: after the service requested by the EP request is not activated, initiate a service authorization request process to the core network; and determine, according to the indication of the core network, that the EP request is activated. After the service has been authorized, the EP activation service information is saved in the context information of the EP.

Optionally, the processor 601 is specifically configured to: after the EP requests to deactivate the service, update the activated service information saved in the context information of the EP.

Optionally, the processor 601 is further configured to: after determining that the authorized service needs to be updated, notify the core network to update the authorized service.

Optionally, the processor 601 is specifically configured to: after the core network notifies that the authorized service needs to be updated, update the authorized service of the corresponding cluster.

Optionally, the processor 601 is further configured to: after updating the authorized service of the corresponding cluster, according to the updated authorized service, after determining that the EP needs to be deactivated, notify the EP that needs to be deactivated to perform the deactivation operation. And update the activation service information in the context information of the EP of the deactivation operation.

Optionally, the DSC functional entity is a mobile terminal or base station type device or a server type device or a distributed service center; and/or

The EP is a mobile terminal or a wearable device or a machine type device.

In FIG. 6, a bus architecture (represented by bus 600), bus 600 may include any number of interconnected buses and bridges, and bus 600 will include one or more processors represented by processor 601 and memory represented by memory 604. The various circuits are linked together. The bus 600 can also link various other circuits, such as peripherals, voltage regulators, and power management circuits, as is known in the art, and therefore, will not be further described herein. Bus interface 603 provides an interface between bus 600 and transceiver 602. Transceiver 602 can be an element or a plurality of elements, such as a plurality of receivers and transmitters, providing means for communicating with various other devices on a transmission medium. Data processed by processor 601 is transmitted over wireless medium via antenna 605. Further, antenna 605 also receives the data and transmits the data to processor 601.

The processor 601 is responsible for managing the bus 600 and the usual processing, and can also provide various functions including timing, peripheral interfaces, voltage regulation, power management, and other control functions. The memory 604 can be used to store data used by the processor 601 in performing operations.

Optionally, the processor 601 may be a CPU (Central Embedded Device), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a CPLD (Complex Programmable Logic Device). , complex programmable logic devices).

As shown in FIG. 7, the second core network device in this embodiment of the present application includes:

The processor 701 is configured to read a program in the memory 704 and perform the following process:

Determining a DSC functional entity that requires authorization; authorizing the determined DSC functional entity by the transceiver 702 to enable the DSC functional entity to manage the EP in the cluster, wherein the DSC functional entity is connected to each EP in the corresponding cluster .

The transceiver 702 is configured to receive and transmit data under the control of the processor 701.

Optionally, the processor 701 is further configured to: after authorizing the determined DSC function entity, update the cluster information corresponding to the DSC function entity according to the cluster information notified by the received DSC function entity.

In FIG. 7, a bus architecture (represented by bus 700), which may include any number of interconnected buses and bridges, will include one or more processors represented by processor 701 and memory represented by memory 704. The various circuits are linked together. The bus 700 can also link various other circuits, such as peripherals, voltage regulators, and power management circuits, as is known in the art and, therefore, will not be further described herein. Bus interface 703 provides an interface between bus 700 and transceiver 702. Transceiver 702 can be an element or a plurality of elements, such as multiple receivers and transmitters, providing means for communicating with various other devices on a transmission medium. The data processed by the processor 701 is transmitted over the wireless medium via the antenna 705. Further, the antenna 705 also receives the data and transmits the data to the processor 701.

The processor 701 is responsible for managing the bus 700 and the usual processing, and can also provide various functions including timing, peripheral interfaces, voltage regulation, power management, and other control functions. The memory 704 can be used to store data used by the processor 701 in performing operations.

Optionally, the processor 701 can be a CPU, an ASIC, an FPGA, or a CPLD.

Based on the same inventive concept, the embodiment of the present application further provides a method for managing a terminal, where the device corresponding to the method is a device in a system for managing a terminal in the embodiment of the present application, and the method solves the problem. Similar to the system, so the implementation of the method can refer to the implementation of the system, and the details are not repeated here.

As shown in FIG. 8, the first method for managing a terminal in the embodiment of the present application includes:

Step 801: The DSC functional entity determines to obtain the core network authorization.

Step 802: The DSC function entity manages EPs in the cluster, where the DSC function entity is connected to each EP in the corresponding cluster.

Optionally, the DSC function entity manages the EPs in the cluster, including: the DSC function entity performs identity verification on the EP when the EP performs an attach process, and establishes the EP after the verification is passed. Contextual information.

Optionally, after the verification is passed, the DSC function entity further includes: the DSC function entity notifying the core network to update corresponding cluster information.

Optionally, before the performing the attach process, the DSC function entity further includes: the DSC function entity broadcasts the access configuration information by using an air interface.

Optionally, the DSC function entity manages the EP in the cluster, and the DSC function entity deletes the context information of the EP in the EP detach process.

Optionally, the method further includes: after the EP detaching is completed, the DSC function entity notifies the core network to update the corresponding cluster information.

Optionally, the DSC function entity manages the EP in the cluster, and the DSC function entity updates the context information of the EP after receiving the status update request of the EP, and notifies the core network. Update the corresponding cluster information.

Optionally, the DSC function entity manages the EPs in the cluster, including:

Determining, by the DSC function entity, the service requested by the EP according to the received service identifier or terminal type information from the EP;

The DSC function entity saves the EP activation service information into the context information of the EP after the service requested by the EP is authorized.

Optionally, the DSC function entity determines, according to the received service identifier or terminal type information from the EP, the service that the EP requests to activate, and further includes:

After the service requested by the EP request is not activated, the DSC function entity initiates a service authorization request process to the core network;

The DSC function entity saves the EP activation service information to the context information of the EP after determining that the service requested by the EP request has been authorized according to the indication of the core network.

Optionally, the DSC function entity manages the EPs in the cluster, including:

The DSC function entity updates the activation service information saved in the context information of the EP after the EP requests to deactivate the service.

Optionally, the DSC function entity, after the EP requests to deactivate the service, further includes: the DSC function entity notifying the core network to update the authorized service after determining that the authorized service needs to be updated.

Optionally, the DSC function entity manages the EP in the cluster, and the DSC function entity updates the authorized service of the corresponding cluster after the core network notifies that the authorized service needs to be updated.

Optionally, after updating the authorization service of the corresponding cluster, the DSC function entity further includes:

The DSC function entity notifies the EP that needs to be deactivated to perform the deactivation operation, and updates the activation service information in the context information of the EP of the deactivation operation, after determining that the EP needs to be deactivated according to the updated authorization service.

Optionally, the DSC functional entity is a mobile terminal or base station type device or a server type device or a distributed service center; and/or

The EP is a mobile terminal or a wearable device or a machine type device.

As shown in FIG. 9, the second method for managing a terminal in the embodiment of the present application includes:

Step 901: The core network device determines a DSC functional entity that needs to be authorized;

Step 902: The core network device authorizes the determined DSC function entity, so that the DSC function entity manages the EP in the cluster, where the DSC function entity is connected to each EP in the corresponding cluster.

Optionally, after the core network device authorizes the determined DSC function entity, the method further includes:

The core network device updates the cluster information corresponding to the DSC functional entity according to the cluster information notified by the received DSC function entity.

In the following, the EP is used as a terminal to enumerate several examples to describe the management of the EP in the cluster by the DSC functional entity of the present application.

For example, as shown in FIG. 10, the terminal in the embodiment of the present application attaches a network process.

For the attach process, since the terminal is invisible to the core network, the core network does not store the subscription information of the terminal in advance, so the access control and authentication functions for the terminal are managed by the DSC functional entity, for example, the identity of the sensor type terminal by the factory administrator The authentication information is manually configured to the DSC functional entity, and the DSC functional entity controls the access of the terminal (including authentication during the terminal access process), and the security scheme adopted between the sensor type terminal and the DSC functional entity can be used by the factory. User-defined (so the security mechanisms used by the terminal and DSC functional entities are not controlled by the operator).

Step 1: The DSC function entity sends the system broadcast information in a broadcast manner, where the network identifier, the DSC function entity identifier, the DSC function entity support service list information, and the configuration information required by the terminal to initiate the access procedure are carried.

Step 2: The terminal performs a network selection process according to the type of the device and the type of the network to be accessed according to the broadcast message, and initiates the network access process according to the access configuration information obtained from the system broadcast message after completing the network selection. In the network access process, the terminal sends an attach request message to the DSC function entity, where the terminal carries the fixed identifier information of the terminal and the terminal identity verification information.

Step 3: The DSC function entity verifies the identity of the terminal identity according to the terminal identity verification information received from the terminal and the fixed identity information of the terminal.

Step 4: After the terminal identity is verified by the legality, the DSC function entity sends an attach response message to the terminal, where the DSC function entity carries the temporary identifier and the DSC function entity identity authentication information, and the terminal fixed identifier information auxiliary terminal pair The message is received downstream.

Step 5: The terminal legally accesses the DSC functional entity according to the received DSC function entity identity verification information. Sexual verification.

Step 6: After the terminal verifies the validity of the DSC function entity, the terminal sends an attach complete message to the DSC function entity, and can also carry the terminal temporary identifier to help the DSC function entity determine the terminal information.

Optionally, the terminal can also enable a status update timer.

Step 7: After receiving the attach complete message, the DSC function entity indexes the context established by the terminal locally according to the terminal temporary identifier, and updates the terminal state to be successfully attached. The DSC function entity turns on the status update timer for the terminal.

Step 8: The DSC function entity updates the currently accessed terminal quantity information, and sends the access terminal quantity information to the core network through the cluster information update process.

For example, as shown in FIG. 11, the terminal in the embodiment of the present application triggers a detachment (Detach logout) process.

Step 1: The de-attach (or logout) process is triggered before the terminal is removed or shut down.

Step 2: The terminal sends a detach request message to the DSC function entity, where the terminal temporary identifier can be carried.

Step 3: The DSC function entity deletes the context information of the terminal.

Step 4: The DSC function entity sends an attach response message to the terminal, where the terminal temporary identifier can be carried.

Step 5: The DSC function entity updates the currently accessed terminal quantity information, and sends the access terminal quantity information to the core network through the cluster information update process.

For example, as shown in FIG. 12, the terminal in this embodiment touches the periodic state update process.

After the terminal is successfully attached to the network, the terminal and the DSC functional entity will respectively start the status update timer. After the timer expires, the terminal initiates a status update process to the network. If the DSC function entity does not receive the status update message of the terminal after the timer T1 expires, the DSC function entity considers that the terminal is in an abnormal state of attachment, and after the timer T2 expires. Implicit release of the terminal context.

Step 1: After the status update timer expires, the terminal triggers a periodic status update process.

Step 2: The terminal sends a status update request message to the DSC function entity, and can simultaneously carry the temporary identifier of the terminal.

Step 3: The DSC function entity determines the terminal context according to the temporary identifier of the terminal, and updates the terminal state information in the terminal context. For example, resetting, that is, updating the timing T1, and setting the terminal status to "abnormal" (when the terminal is in the "abnormal" state, the network can stop providing communication services to the terminal).

Step 4: The DSC function entity sends a status update response message to the terminal, and can simultaneously carry the temporary identifier of the terminal.

Step 5: If the terminal does not receive the status update message from the terminal after the T2 time expires after the status update timer T1 expires, the DSC function entity considers that the terminal implicitly leaves the network.

Optionally, after determining that the terminal implicitly leaves the network, the DSC function entity may locally release the terminal context and initiate a cluster (group) information update process to the core network, for example, updating the terminal quantity information in the cluster.

For example, as shown in FIG. 13, the terminal in this embodiment triggers a service activation process.

Step 1: The terminal initiates a service activation request when the new service needs to be activated, and carries the service identification information or the terminal type information through the service request message.

For example, the terminal is a camera device that requests real-time video backhaul services; and, for example, the terminal is a sensor that requests real-time backhaul services for data samples collected by the sensor.

Step 2: The DSC function entity determines whether it has been authorized by the core network to provide corresponding services (such as real-time video backhaul) to members in the cluster. If it is already authorized, go directly to step 4; otherwise, go to step 3.

Step 3: If the DSC function entity is not authorized by the core network to provide corresponding services (such as real-time video backhaul) to the members in the cluster, the DSC function entity initiates a cluster service authorization update request process to the core network. The core network will indicate whether the DSC functional entity can provide new service types within the cluster. The core network records the cluster-activated service type managed by the DSC functional entity. The DSC function entity will update the cluster authorization service list information saved locally. If the core network authorization is not obtained, the service request of the terminal is rejected; if the core network is authorized, step 4 is performed.

Step 4: If the DSC function entity is authorized by the core network to provide a corresponding service type (for example, real-time video backhaul), the DSC function entity sends a service activation response message to the terminal. The terminal temporary identification information can be carried and used for terminal reception.

Step 5: After the service is activated, the terminal sends a service activation complete message to the DSC function entity, and carries the terminal temporary identifier.

Step 6: The DSC function entity updates the state information of the terminal activation service in the locally saved terminal context.

For example, as shown in FIG. 14, the MTC class terminal in this embodiment initiates a service deactivation process.

Step 1: After the terminal decides to deactivate the service, it sends a service deactivation request to the DSC function entity, which may carry the service identification information or the terminal type information. In addition, the terminal temporary identification information may also be carried to help the DSC functional entity identify the terminal.

Step 2: The DSC function entity determines the service type that the terminal needs to deactivate according to the service identifier or the terminal type, and updates the terminal activation service type information saved in the terminal context.

Step 3: The DSC function entity sends a service deactivation command to the terminal, where the temporary identification information of the terminal may be carried.

Step 4: The terminal sends a service activation completion message to the DSC function entity, where the terminal temporary identification information can be carried.

Step 5: The DSC function entity determines whether the authorized service list needs to be updated, and if necessary, initiates a cluster (group) service authorization update process to the core network, and updates the DSC function entity authorized service list.

For example, if the DSC function entity authorization list includes (video real-time backhaul service), and the DSC function entity is responsible for managing the terminal without the terminal that activates the service, the DSC function entity may initiate a cluster (group) service authorization update to the core network. The process updates the DSC functional entity authorized service list.

Step 6: After the DSC function entity determines to update the authorized service list information, the cluster (group) service authorization update process is initiated to the core network.

For example, as shown in FIG. 15, the service deactivation process triggered by the core network in the embodiment of the present application.

Step 1: In the case that the core network expires or fails some or all of the service authorizations authorized by the specific DSC functional entity (for example, when the time-based service authorization occurs timeout, or the user account corresponding to the DSC functional entity is in arrears), The core network can initiate a cluster service authorization update process.

Step 2: The DSC function entity locally saves the updated cluster service authorization information.

Step 3: The DSC function entity determines whether a cluster terminal activates an unauthorized service. If there is a terminal whose unauthorized activation service is still active, the DSC function entity will trigger a service deactivation process for the specific terminal.

Step 4: The DSC function entity sends a service deactivation command to the terminal.

If the terminal activates multiple services at the same time, the service identification information may be carried and deactivated. In addition, the terminal temporary identifier may also be used for the terminal to determine whether the message is for itself.

Step 5: After the service is deactivated, the terminal sends a service deactivation completion message to the DSC function entity, which may carry the terminal temporary identification information.

Step 6: After receiving the service deactivation completion message, the DSC function entity updates the activated service information in the locally saved terminal context.

As can be seen from the foregoing, the DSC function entity in the embodiment of the present application manages the EPs in the cluster after determining the authorization of the core network, where the DSC function entity is connected to each EP in the corresponding cluster. Since the EPs in the cluster are managed by the DSC functional entity, the burden on the core network is not increased after the number of terminals of the machine type is increased, thereby avoiding the signaling storm caused by the excessive burden of the core network.

It will be apparent to those skilled in the art that various modifications and changes can be made in the present application without departing from the spirit and scope of the application. Thus, it is intended that the present invention cover the modifications and variations of the present invention.

Claims (32)

A method for managing a terminal, the method comprising: The distributed service center DSC functional entity determines to obtain the core network authorization; The DSC functional entity manages the end nodes EP in the cluster, wherein the DSC functional entities are connected to each EP in the corresponding cluster. The method of claim 1, wherein the DSC functional entity manages the EPs in the cluster, including: The DSC function entity authenticates the EP when the EP performs an attach process, and establishes context information of the EP after the verification is passed. The method of claim 2, wherein the DSC functional entity further comprises: after the verification is passed: The DSC function entity notifies the core network to update the corresponding cluster information. The method of claim 2, wherein the DSC functional entity further comprises: before the EP performs the attaching process: The DSC function entity broadcasts the access configuration information through an air interface. The method of claim 1, wherein the DSC functional entity manages the EPs in the cluster, including: The DSC function entity deletes context information of the EP in the EP detach process. The method of claim 5, further comprising: After the EP detachment is completed, the DSC function entity notifies the core network to update the corresponding cluster information. The method of claim 1, wherein the DSC functional entity manages the EPs in the cluster, including: After receiving the status update request of the EP, the DSC function entity updates the context information of the EP, and notifies the core network to update the corresponding cluster information. The method of claim 1, wherein the DSC functional entity manages the EPs in the cluster, including: Determining, by the DSC function entity, the service requested by the EP according to the received service identifier or terminal type information from the EP; The DSC function entity saves the EP activation service information into the context information of the EP after the service requested by the EP is authorized. The method according to claim 8, wherein the DSC function entity determines, according to the received service identifier or terminal type information from the EP, the service that the EP requests to activate, and further includes: The DSC function entity initiates a service authorization request to the core network after the service requested by the EP request is not activated. process; The DSC function entity saves the EP activation service information to the context information of the EP after determining that the service requested by the EP request has been authorized according to the indication of the core network. The method of claim 1, wherein the DSC functional entity manages the EPs in the cluster, including: The DSC function entity updates the activation service information saved in the context information of the EP after the EP requests to deactivate the service. The method of claim 10, wherein the DSC function entity further includes: after the EP requests to deactivate the service: After determining that the authorized service needs to be updated, the DSC function entity notifies the core network to update the authorized service. The method of claim 1, wherein the DSC functional entity manages the EPs in the cluster, including: After the core network notifies that the authorized service needs to be updated, the DSC function entity updates the authorized service of the corresponding cluster. The method according to claim 12, wherein after updating the authorization service of the corresponding cluster, the DSC function entity further includes: The DSC function entity notifies the EP that needs to be deactivated to perform the deactivation operation, and updates the activation service information in the context information of the EP of the deactivation operation, after determining that the EP needs to be deactivated according to the updated authorization service. The method according to any one of claims 1 to 13, wherein the DSC functional entity is a mobile terminal or base station type device or server type device or a distributed service center; and/or The EP is a mobile terminal or a wearable device or a machine type device. A method for managing a terminal, the method comprising: The core network device determines the DSC functional entity that needs to be authorized; The core network device authorizes the determined DSC functional entity to enable the DSC functional entity to manage the EPs in the cluster, wherein the DSC functional entity is connected to each EP in the corresponding cluster. The method according to claim 15, wherein after the core network device authorizes the determined DSC function entity, the method further includes: The core network device updates the cluster information corresponding to the DSC functional entity according to the cluster information notified by the received DSC function entity. A DSC functional entity that manages a terminal, wherein the DSC functional entity includes: a first determining module, configured to determine to obtain a core network authorization; a management module for managing EPs in the cluster, wherein the DSC functional entity and each EP in the corresponding cluster connection. The DSC functional entity according to claim 17, wherein the management module is specifically configured to: When the EP performs the attaching process, the EP is authenticated, and the context information of the EP is established after the verification is passed. The DSC functional entity according to claim 18, wherein the management module is further configured to: After the verification is passed, the core network is notified to update the corresponding cluster information. The DSC functional entity according to claim 18, wherein the management module is further configured to: Before the EP performs the attach process, the access configuration information is broadcast through the air interface. The DSC functional entity according to claim 17, wherein the management module is specifically configured to: The context information of the EP is deleted during the EP detach process. The DSC functional entity according to claim 21, wherein the management module is further configured to: After the EP detachment is completed, the core network is notified to update the corresponding cluster information. The DSC functional entity according to claim 17, wherein the management module is specifically configured to: After receiving the status update request of the EP, the context information of the EP is updated, and the core network is notified to update the corresponding cluster information. The DSC functional entity according to claim 17, wherein the management module is specifically configured to: Determining, according to the received service identifier or terminal type information from the EP, the service that the EP requests to be activated; and after the EP requesting the activated service has been authorized, saving the EP activation service information to the context information of the EP in. The DSC functional entity according to claim 24, wherein the management module is further configured to: After the service requested by the EP is not activated, the service authorization request process is initiated to the core network; and after determining that the service requested by the EP request has been authorized, the EP activation service information is saved according to the indication of the core network. Go to the context information of the EP. The DSC functional entity according to claim 17, wherein the management module is specifically configured to: After the EP requests to deactivate the service, the activated service information saved in the context information of the EP is updated. The DSC functional entity according to claim 26, wherein the management module is further configured to: After determining that the authorized service needs to be updated, the core network is notified to update the authorized service. The DSC functional entity according to claim 17, wherein the management module is specifically configured to: After the core network notifies that the authorized service needs to be updated, the authorized service of the corresponding cluster is updated. The DSC functional entity according to claim 28, wherein the management module is further configured to: After updating the authorization service of the corresponding cluster, according to the updated authorization service, after determining that the EP needs to be deactivated, notifying the EP that needs to be deactivated to perform the deactivation operation, and updating the context information of the EP of the deactivation operation Activate business information. The DSC functional entity according to any one of claims 17 to 29, wherein the DSC functional entity is a mobile terminal or base station type device or a server type device or a distributed service center; and/or The EP is a mobile terminal or a wearable device or a machine type device. A core network device for managing a terminal, where the core network device includes: a second determining module, configured to determine a DSC functional entity that needs to be authorized; And a processing module, configured to authorize the determined DSC function entity, so that the DSC function entity manages the EPs in the cluster, where the DSC function entity is connected to each EP in the corresponding cluster. The core network device according to claim 31, wherein the processing module is further configured to: After the determined DSC function entity is authorized, the cluster information corresponding to the DSC function entity is updated according to the cluster information notified by the received DSC function entity.

Images