WO2019242574A1 - 一种物联网业务路由的方法 - Google Patents

一种物联网业务路由的方法 Download PDF

Info

Publication number
WO2019242574A1
WO2019242574A1 PCT/CN2019/091448 CN2019091448W WO2019242574A1 WO 2019242574 A1 WO2019242574 A1 WO 2019242574A1 CN 2019091448 W CN2019091448 W CN 2019091448W WO 2019242574 A1 WO2019242574 A1 WO 2019242574A1
Authority
WO
WIPO (PCT)
Prior art keywords
network slice
service
target network
terminal device
iot platform
Prior art date
Application number
PCT/CN2019/091448
Other languages
English (en)
French (fr)
Inventor
张永靖
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP19823643.2A priority Critical patent/EP3800934A4/en
Publication of WO2019242574A1 publication Critical patent/WO2019242574A1/zh
Priority to US17/126,772 priority patent/US11716669B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/16—Performing reselection for specific purposes
    • H04W36/22—Performing reselection for specific purposes for handling the traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]

Definitions

  • the present application relates to the field of communications, and in particular, to a method, an apparatus, and a system for routing IoT services.
  • next-generation mobile communication network architecture ie, 5G network architecture
  • the physical network can be abstracted into multiple network slices, each of which constitutes one End-to-end logical networks are logically isolated from each other.
  • Each slice can flexibly provide one or more network services according to the requirements of the demand side, and does not affect each other in the network.
  • eMBB Enhanced Mobile Broadband
  • uRLLC Ultra-reliable ultra-reliable communications
  • mMTC Massive Machine Communication
  • uRLLC slicing is required to ensure high reliability and low-latency communication requirements during autonomous driving.
  • eMBB slicing is required to ensure large bandwidth communication requirements such as in-vehicle infotainment.
  • mMTC slices are needed to support massive meter reading services, and uRLLC slices are required to support real-time and reliable pipe network line monitoring to avoid disasters.
  • multiple industry applications may use a unified IoT platform (or platform for short) to manage terminal devices or access business data related to terminal devices. Connected through one or more network slices of the operator. Therefore, there is also a need for a single platform to use multiple network slices simultaneously.
  • the 5G network architecture defined by 3GPP allows a terminal device to access and use multiple network slices at the same time, it limits the use of different application identities for terminal devices accessing different network slices, that is, an application-related service message can only use a single The network slice for message transmission cannot meet the needs of a single industry application using multiple network slices for communication.
  • the existing technology does not solve the problem of how industry applications or IoT platforms choose the appropriate network slice to communicate with terminal devices. .
  • the embodiments of the present application provide a method for routing IoT services.
  • a mapping relationship between service features and network slices on the IoT platform or establishing a routing strategy that determines network slices based on service characteristics
  • the IoT platform or simply platform
  • Based on the service characteristics of business messages sent by industry applications it is possible to select appropriate network slices to communicate with terminal devices to meet the various network requirements of industry applications.
  • the IoT platform can obtain network slice information (including slice identifiers and / or slice network element addresses) and slice-related service characteristics from industry applications, UEs, or the underlying network. For example, when an industry application provider or operator has directly contracted with a network operator to purchase a network slicing service in advance, the network slicing information and the slicing-related business features are configured in advance on the industry application or terminal device, and then through the industry application or The registration or configuration message of the terminal device sends network slicing information and service characteristics related to the slicing to the platform; or when the industry application provider or operator has not previously signed a contract with a network operator to purchase a network slicing service, the IoT platform can First, obtain service level requirements and service feature descriptions from industry applications, and then purchase network slice services, create network slices, and obtain network slice information from the underlying network operator based on the service level requirements.
  • network slice information including slice identifiers and / or slice network element addresses
  • the IoT platform establishes a mapping relationship between network slices and service features, which is equivalent to establishing a service routing policy that determines network slices based on service characteristics.
  • the service routing policy specifies the network from which service messages of different characteristics should be sent.
  • the slices are delivered to the terminal device, thereby ensuring the service level requirements for transmitting different business messages between industry applications and terminal devices.
  • the IoT platform When the IoT platform receives a service message sent by an industry application to a terminal device, the IoT platform parses the service characteristics in the service message and matches the stored service routing policy to select the network slice direction The terminal device sends a service message.
  • the IoT platform can also establish a service routing policy for the terminal device and deliver it to the terminal device.
  • the terminal device stores the received service routing policy, and when sending a service message, selects a corresponding network slice to send a service message according to the service characteristics of the service message.
  • eSIM Embedded-Subscriber Identity Module
  • the slicing-related service characteristics may include allowing or disabling service characteristics sent through a specific slice to achieve management of network slice resources and traffic, and to prevent network slice resources from being unnecessary (such as unauthorized, irrelevant). (Malicious) business flow abuse, to realize the filtering control of the Internet of Things platform on the specific network slice business flow.
  • the method for IoT service routing proposed in this application relates to IoT platforms, industry application servers, terminal devices and other devices. Therefore, the present application also provides a device for implementing the above-mentioned method for routing IoT services.
  • the present application also provides a computer-readable storage medium, where the computer-readable storage medium stores instructions, and when the computer-readable storage medium runs on the computer, causes the computer to execute the foregoing method of routing an Internet of Things service.
  • the present application provides a computer program product containing instructions that, when run on a computer, causes the computer to perform the method for routing IoT services described above.
  • FIG. 1 is an IoT system architecture applicable to this application
  • FIG. 3 is a schematic flowchart of an Internet of Things service routing method according to an embodiment of the present invention.
  • FIG. 4 is a flowchart of a method for routing IoT services in a scenario where an industry application manages network slices through an IoT platform according to an embodiment of the present invention
  • FIG. 5 is a flowchart of a method for routing an IoT service in a scenario where an IoT platform obtains network slice information from an industrial application according to an embodiment of the present invention
  • FIG. 6 is a flowchart of a method for routing an IoT service in a scenario where an IoT platform obtains network slice information from a terminal device according to an embodiment of the present invention
  • FIG. 7 is a flowchart of another method for routing IoT services according to an embodiment of the present invention.
  • FIG. 8 is a schematic diagram of a device according to an embodiment of the present invention.
  • Figure 1 shows an IoT system architecture involved in an embodiment of this application, including industry applications (referring to applications that provide services to specific industries, or applications that provide services in specific scenarios or environments, such as smart homes, car networking , Industrial manufacturing and smart cities, etc.), IoT platforms (or platforms for short), underlying networks and terminal equipment; among them, industry applications communicate with terminal equipment through the platform, and platforms and terminal equipment connect and communicate through the underlying network, terminal equipment You can access the underlying network through a variety of connection methods (such as wired or wireless access) and access protocols (such as WIFI, ZigBee, Bluetooth, Narrowband Internet of Things, NB-IoT, 5G, etc.).
  • connection methods such as wired or wireless access
  • access protocols such as WIFI, ZigBee, Bluetooth, Narrowband Internet of Things, NB-IoT, 5G, etc.
  • the invention embodiments are not limited.
  • the so-called low-level network refers to the application layer where the industry application is located.
  • the transmission network at the bottom of the protocol stack can be called the low-level network as long as the network that can communicate between the platform and the terminal device.
  • the underlying network can be divided into multiple network slices (or virtual networks). Each network slice is divided according to network requirements (such as delay, bandwidth, security, and reliability). In different business scenarios, platforms and terminals Devices communicate using network slices that match network requirements.
  • the system architecture shown in FIG. 1 can be further refined into the system architecture shown in FIG. 2.
  • the 3GPP network provides network slicing and communication services based on network slicing, such as communication via user plane function (UPF) and communication via network open function (NEF).
  • the 3GPP network also provides a network Slice management functions, such as creating network slices and querying information through the network slice management function (NSMF).
  • the 3GPP network also includes network elements defined by 3GPP standards, such as radio access network (RAN), access management function (AMF), and policy control function (PCF). No longer. According to the needs of network deployment, the above-mentioned network elements may have zero, one, or multiple instances in one network slice.
  • RAN radio access network
  • AMF access management function
  • PCF policy control function
  • the platform obtains information about a network slice and service characteristics corresponding to the network slice. It should be noted that, in different service scenarios, the platform may obtain network slice information and service characteristics corresponding to the network slice in different ways.
  • Business scenario a Industry application providers or operators manage network slicing through the platform: In this business scenario, industry application providers or operators will not directly purchase network slicing services from the underlying network operator, and industry applications send services to the platform. Level requirements (service level agreement, SLA). The platform purchases network slicing services and creates network slices from the underlying network operators according to the SLA requirements of industry applications, so that industry applications and terminal devices can communicate through network slices that match the SLA. specific,
  • SLA can be understood as the quality of service (QoS) and service capability requirements required by industry applications to meet one or more characteristics of business stream transmission, including but not limited to bandwidth, delay, jitter, and reliability Parameters such as security, isolation, mobility, sleep period, cache size, location area, roaming ability, whether synchronization, etc.
  • QoS quality of service
  • the SLA may be sent to the platform in the form of the above parameter list, or a number of configuration options (Profile) based on the above parameter list may be set in the platform and selected by industry applications (such as sending configuration options). ID or type).
  • Profile configuration options
  • the business characteristics described in this application include, but are not limited to, source / destination application identification, source / destination middleware identification, resource identification or type, message type (request / response), or operation method (such as C / R common in RESTful API calls / U / D / N operation, which represents one or more characteristics such as creating or obtaining or updating or deleting or notifying, and message priority.
  • the platform selects an existing network slice or creates a new network slice for industry applications according to the SLA. For example, when there is a network slice that can satisfy the SLA in one or more existing network slices that are connected to the platform, the platform can select a network slice that meets the SLA to serve applications in the industry. If there is no network slice that meets the SLA (such as delay or bandwidth requirements), the platform needs to interact with the underlying network and request the underlying network to create a new network slice that meets the SLA requirements (as shown in Figure 2 as For example, request the NSMF to create a network slice), and obtain the information of the new network slice (such as taking FIG.
  • the platform obtain the information of the network slice from NSMF), and establish a connection with the newly created network slice (such as using FIG. 2 as For example, establishing a connection with UPF and NEF), the establishing the connection includes establishing a related transport network / link layer channel (such as establishing a tunnel, a VLAN, etc.), a network layer secure connection, and the like.
  • a related transport network / link layer channel such as establishing a tunnel, a VLAN, etc.
  • a network layer secure connection and the like.
  • network slice information described in this application includes, but is not limited to, network slice identification, network slice name, network slice type, operator identifier or name, and network element address (including IP address and transport layer) of the network slice. Message) and so on.
  • Business scenario b Industry applications purchase network slice services directly from the underlying network operator.
  • the information about the purchased network slices and the business features corresponding to the network slices have been configured in the industry application in advance:
  • the industry application sends the information of the purchased network slice and the service characteristics corresponding to the network slice to the platform, and the platform establishes a connection with the network slice (for example, as shown in FIG. 2, establishes a connection with UPF and NEF) .
  • Business scenario c Similar to business scenario b, industry applications purchase network slice services directly from the underlying network operator. The difference from business scenario b is that information about network slices purchased by industry applications and business characteristics corresponding to the network slices It has been configured in the terminal device in advance:
  • the terminal device sends information about network slices purchased by industry applications and service characteristics corresponding to the network slices to the platform, and the platform establishes a connection with the network slices (for example, as shown in FIG. 2, establishing a connection with UPF and NEF connection).
  • the platform can also choose to further obtain the supplementary information of the network slice from the underlying network according to whether the information of the network slice is complete, as shown in 301a3, 301b2, Step 301c2.
  • steps 301a2, 301b1, or 301c1 only the name or identifier of the network slice is provided, but the necessary network element addresses and related transport layer information (such as tunnel identification, VLAN-ID, etc.) in the network slice are not provided; or only part of it is provided.
  • Network element address information such as UPF address
  • the rest of the network element address information such as NEF address
  • the platform can initiate a network slice information query request to the underlying network (such as Figure 2 for example, query NSMF), according to Name / identity / partial network element address information of the network slice to obtain the required network element address information and related transmission channel information.
  • the platform records the corresponding relationship between the network slice and the service feature, as shown in Table 1. That is, the corresponding network slice and the information of the network slice can be determined by the service feature, or the corresponding service can be determined by the information of the network slice.
  • the characteristics are equivalent to the establishment of a service routing strategy for selecting network slices based on service characteristics.
  • the service routing strategy can be further refined into an uplink service routing strategy and a downlink service routing strategy.
  • the uplink service routing strategy can be sent to the terminal device (see step 305).
  • the downlink service routing strategy is used by the platform.
  • the platform selects the downlink service routing strategy.
  • the network slice sends a downlink service message.
  • the platform receives a downlink service message sent by an industry application to a terminal device.
  • the platform parses the downlink service message, obtains the service feature in the service message, and determines a network slice corresponding to the service feature, that is, a target network slice.
  • the platform sends a service message to the terminal device through the target network slice.
  • the platform may also send the network slice information and the network slice information corresponding to the network slice to the terminal device after obtaining the correspondence between the information and network characteristics of the network slice.
  • Service characteristics to enable a terminal device to establish an uplink service routing policy that is, to record a network slice and a service characteristic corresponding to the network slice. It should be noted that the network slice information and corresponding service characteristics do not have to be sent to the terminal device at the same time.
  • the IoT platform may also include only the network slice to be accessed by the terminal device in the 305 message, without including the service characteristic information, or In other messages, the service characteristics corresponding to the network slice information are delivered to the terminal device.
  • a suitable network slice is selected to send the uplink service messages. This application does not limit the sequence of steps 305 and 302, 303, and 304.
  • the solutions provided in the embodiments of the present application can not only enable applications in the same industry to communicate with terminal devices using different network slices, but also enable a terminal or platform to select network slices based on service layer parameters and granularity such as service characteristics. It meets the needs of industry applications or terminals to flexibly use network slicing based on message types and data resources accessed.
  • the service characteristics corresponding to the network slice as described above can be further divided into allowed service features and prohibited service features (as shown in Table 2), so as to realize the management of network slice resources and traffic and avoid the network Slicing resources are abused by non-essential (such as unauthorized, irrelevant, malicious) service flows to achieve filtering control of IoT platform's specific network slice service flows.
  • the platform obtains a service feature in step 303, it is preferred to determine whether the service feature is a prohibited service feature or an allowed service feature. If it is a prohibited service feature, the platform will not send a downlink message through the network slice corresponding to the service feature. That is, step 304 will not be performed. If it is an allowed business feature, the platform will perform step 304.
  • FIG. 3 The schematic method flow shown in FIG. 3 can be further supplemented and detailed in the business scenario a into the method flow shown in FIG. 4.
  • the platform may query whether there are already network slices in the underlying network that can meet the service level requirements described in step 1. If so, the platform will select one or more network slices that meet the conditions to serve the industry application (and the terminal equipment associated with it), and skip steps 403-405. If not, for example, the service level requirements that require the transmission of service flows need to be isolated from other industry applications, or parameters such as delay / bandwidth cannot meet the requirements, it means that a new network slice needs to be created to serve the service flow , So steps 403-405 will be performed.
  • the platform requests the underlying network (such as NSMF) to create a network slice that meets the service level requirements, and the request includes the description parameters corresponding to the service level requirements described in step 401.
  • the description parameter is different from the description parameter (slicing template) that the network slice manager can accept
  • the platform also needs to do corresponding mapping or conversion, including but not limited to: parameter name mapping, unit conversion, and parameter decomposition (Such as the end-to-end delay of the industry application to the terminal device minus the delay of the industry application to the platform, so as to obtain the delay of the network slice between the terminal device and the platform), the filtering of parameters (such as excluding network-independent Number of concurrent business messages / frequency).
  • the underlying network creates a corresponding network slice in the underlying network according to the request in step 403.
  • the platform obtains information about the network slice created from the underlying network.
  • step 405 when the network slice information obtained in step 405 is incomplete, the platform can further obtain supplementary information about the network slice from the underlying network.
  • the platform establishes a connection with the network slice.
  • the platform According to the network slice information obtained in steps 405-407 and the service characteristics obtained in step 401, the platform generates corresponding uplink and downlink service routing policies, as shown in Table 1 or Table 2.
  • the terminal device will register to the platform through the default network slice. This step can occur at any time before steps 401-408, that is, it does not depend on the interaction results between the platform and industry applications and the underlying network, and is independent of the time sequence of steps 401-408.
  • the platform configures the uplink service routing policy for the terminal device, and the configuration can be issued in various ways, including through a service registration response message of the terminal device, through a device management command, through a special service configuration message, Open API release through network capabilities, release through eSIM process, etc. specific:
  • the platform can determine which terminal devices need to be configured with the corresponding uplink service routing policy, so as to perform the configuration operation of step 410; in addition, the platform may also need to interact with the underlying network to provide the terminal
  • the device configures the subscription data required to access the relevant network slice, as shown in step 411. For example, the platform interacts with the user data management network element of the underlying network through NEF, and configures the contract data that allows terminal devices to access the network slice.
  • the platform may temporarily not perform this Step, but wait until step 414, determine the network slice that the terminal device should access according to the service characteristics of the downlink service message sent to the terminal device in step 414, and then perform the terminal device described in this step.
  • the IoT platform may only include information about network slices that the terminal device needs to access in the 410 message, and the service characteristics corresponding to the network slice may not be sent to the terminal device or sent to the terminal device in other messages.
  • the 410 message may be a configuration message or a separate trigger message.
  • the platform may use the configuration message or the independent trigger message to trigger the terminal device to perform the re-registration process described in step 412.
  • the terminal device selects to access the network slice in the policy according to the uplink service routing policy configured in step 410, and re-registers with the platform through the new network slice. If the network slice in the policy is exactly the default network slice used by the terminal device in step 409, the terminal device does not need to perform this step.
  • a terminal device needs to access multiple network slices at the same time, it can re-register to the platform once through each network slice, or it can be further optimized to select one of the network slices to complete the re-registration related to all network slices at one time (which carries other Necessary information for network slicing, such as the addressing information of the terminal device in each network slice (such as identification, IP address, access point (PoA, etc.), etc.), such as the terminal device passing the default network slice in step 409 Register, and re-register again through the default network slice in step 412.
  • the re-registration request includes the information of the terminal device in other network slices.
  • the platform can obtain supplementary information (such as the UPF or NEF address currently serving the terminal device) of the sliced network element from the registration message, and further supplement this information to the downlink generated in step 408 Service routing policy.
  • supplementary information such as the UPF or NEF address currently serving the terminal device
  • the terminal accesses the network slice, it can subsequently select the corresponding network slice and send the uplink service message according to the uplink service routing policy configured in step 410 and the service characteristics of the uplink service message.
  • the method provided in this application can be developed and implemented in various ways.
  • the method flow shown in FIG. 4 can be implemented using the oneM2M standard as a framework.
  • the Internet of Things platform corresponds to the IN-CSE (Common Services Services, Infrastructure, and Node) defined by the oneM2M standard
  • the industry application corresponds to the IN-AE (Application Infrastructure, Infrastructure, and Node) defined by the oneM2M standard.
  • Strong or weak or high or low configuration, different types of terminal devices may correspond to MN (Middle Node) or ASN (Application Service Node) or ADN (Application Dedicated Node) defined by the oneM2M standard.
  • MN Middle Node
  • ASN Application Service Node
  • ADN Application Dedicated Node
  • the message sent in this step may specifically be a registration message sent by the IN-AE to the IN-CSE, such as the creation of an ⁇ AE> resource message, or a separate configuration message, such as the creation of one or more service feature resources ⁇ trafficChar> and one or more associated service level demand resources ⁇ SLA>, or create one or more composite resources ⁇ trafficSLA> containing both service characteristics and service level requirements, or create a service routing policy resource ⁇ nsRoutePolicy> (where (Contains attributes or sub-resources related to service level requirements), or create or update attributes or sub-resources related to business characteristics and business level requirements in the service subscription resource ⁇ serviceSubscriptionProfile>.
  • Service characteristics include: source / destination application identifier (such as APP-ID, AE-ID), source / destination middleware identifier (such as CSE-ID), service resource identifier (such as Resource-ID), and service resource type (such as group, container, mgmtObj type), business message type (such as request req or response resp) or operation method (such as create C / get R / update U / delete D / notify N, etc.), message priority (such as event Category in extended message) The value of the parameter, or one or more of the Flow Type tag added to the message.
  • the manner in which the message carries service characteristics and service level requirements may be resource attributes or sub-resources.
  • the ⁇ AE> resource in oneM2M needs to be expanded to add a composite attribute trafficSLA that contains both service characteristics and service level requirements as an attribute of ⁇ AE>, or a composite resource ⁇ trafficSLA> As a sub-resource of ⁇ AE>, or add a service routing policy resource ⁇ nsRoutePolicy> as a sub-resource of ⁇ AE>.
  • the above-mentioned extended attributes or sub-resources can also exist as attributes or sub-resources of other resources, and do not affect the implementation effect of the solution of this application. Regardless of how it is implemented, the information received by IN-CSE will form the data structure relationship described in Table 3, where the record unit that does not provide a specific value indicates an arbitrary value match or a default value match.
  • the business level requirements can also be classified to form several configurable classifications or levels (such as Profile, Category, Level, etc.), as shown in Table 4:
  • the information in Table 4 itself can exist as a separate resource or attribute, or part of other resources (such as root resource ⁇ CSEBase>, business contract resource ⁇ serviceSubscriptionProfile>, business level requirement resource ⁇ SLA>), and can be pre-configured in IN-CSE can also be created or updated by one or more IN-AE.
  • Table 3 can be simplified into the form of Table 5, and the same service level requirement classification can be reused by different service flows.
  • the description method of service level requirements can be simplified, and the defined service level requirement classification identifier or type can be directly referenced (such as Profile1).
  • the IN-CSE judges that some service flows applied in the industry do not need to be isolated according to the isolation requirements in the service level requirements obtained in step 401, and then queries whether existing network slices in the 3GPP network already exist to satisfy these services. A network slice of the service level requirements corresponding to the flow. If so, the IN-CSE will select one or more network slices that meet the conditions to serve the service flow (and the terminal equipment associated with it). If not, for example, isolation is required in the service level requirements, or parameters such as the delay / bandwidth of the existing network slice cannot meet the requirements, then steps 403-405 are performed.
  • IN-CSE requests the network slice manager NSMF to create a network slice that meets the service level requirements, and maps or converts the description parameters of the service level requirements in the request if necessary. For example: mapping of parameter names (such as latency to delay), conversion of units (such as ms to s), and decomposition of parameters (such as the end-to-end delay of IN-AE to terminal equipment minus IN-AE to IN-CSE Delay in order to obtain the delay of the network slice), filtering of parameters (such as excluding the number / frequency of concurrent business messages that are not related to the network).
  • mapping of parameter names such as latency to delay
  • conversion of units such as ms to s
  • decomposition of parameters such as the end-to-end delay of IN-AE to terminal equipment minus IN-AE to IN-CSE Delay in order to obtain the delay of the network slice
  • filtering of parameters such as excluding the number / frequency of concurrent business messages that are not related to the network.
  • the NSMF creates a corresponding network slice in the underlying network according to the request in step 403.
  • IN-CSE obtains the information of the created network slice from the NSMF.
  • the network slice information includes: slice ID / name (such as NS-NSSAI, NS-ID), slice type (such as eMBB, uRLLC, mMTC), operator identifier / name (such as CMCC, VDF), and slice network element address (Such as the IP addresses of UPF and NEF, and the VLAN ID or tunnel ID of the link layer connection established between IN-CSE and UPF / NEF).
  • the IN-CSE may request the network slice management function NSMF in the 3GPP network to obtain the relevant network in the network slice.
  • Meta supplementary information such as UPF and NEF addresses in the slice, or transport layer information and other information (such as slice type, etc.)
  • the request message sent by IN-CSE to NSMF carries the slice identifier eMBB-A, and obtains the required slice network element address in the response: UPF3: ⁇ IP5 ⁇ ; ⁇ VLAN5 ⁇ , NEF3: ⁇ IP6 ⁇ ; ⁇ VLAN6 ⁇ , Slice type: eMBB, etc.
  • IN-CSE may also be required (based on the relevant identification of the terminal device, such as IMSI, IMEI, External-ID, etc.) Query the specific network element information (or service) of a specific terminal from the NSMF, and make a separate record (divide the resource identifier, application identifier, middleware identifier, etc. of multiple terminal devices into multiple records, corresponding to different sliced network elements. Address transport layer information). Or, after the subsequent terminal device completes the registration or other service message interaction with the IN-CSE, the IN-CSE determines which terminal device (or service ) Network element information.
  • the IN-CSE may also need to query other network element information in the same slice according to some slice NE information. For example, if the UPF address in a slice is obtained in step 405 and the NEF address is missing, the IN-CSE needs Query the associated NEF address in the same slice according to the UPF address, and vice versa.
  • IN-CSE checks whether it has established a connection with the above network slice. If not, it establishes a connection with each relevant network slice according to the network slice information obtained in the above steps (specifically, the network element address and transport layer information of each slice). . For example, IN-CSE needs to establish link-layer and IP-layer connections at UPF1, UPF2, UPF3, NEF1, NEF2, and NEF3 respectively.
  • IN-CSE will generate corresponding uplink and downlink service routing policies.
  • Table 6 and Table 7. For the specific content and form, refer to Table 6 and Table 7. .
  • Tables 3, 4, and 5 can also be combined with Table 6 or Table 7.
  • Each record in Table VI can have one or more unit vacancies. A record unit that is not filled in indicates that any value matches, or the default value matches.
  • Each element in each record can be filled with multiple information, such as "source” and "destination” can be filled with multiple CSE-ID, AE-ID, Resource-ID, "container> can be filled in" resource type " , ⁇ group> and many other resource types, and so on for other unit items.
  • the uplink service routing policy is shown in Table 7. It is used for terminal equipment to make service routing selection for the uplink service flow sent to the IN-CSE.
  • Table 7 also includes network slicing information and service characteristic information related to the slicing. The difference is that the network slicing information in Table 7 is relatively simple, and it is not necessary to slice the network element address information.
  • IN-CSE can create corresponding service routing policy attributes or service routing policy resources for each terminal device, or create shared attributes or resources for them. This can be achieved by associating links to the same service routing policy attribute or resource.
  • the uplink service routing policy different names or types, or associated labels, tag attributes, and other methods can be used to distinguish allowed or forbidden service flows.
  • the AE or CSE on the terminal device is registered to the IN-CSE through the default network slice.
  • IN-CSE determines that the terminal device is registered for the first time (or determines that the registration message of the terminal device comes from a network slice different from the service routing policy generated in step 408), and then configures the uplink service routing policy generated in step 408 to the terminal device.
  • the delivery For example, when the AE or CSE on the terminal device initiates the registration process to the IN-CSE, it is delivered in its registration response message (extended message body content); it can also be managed by a separate device. The command is issued.
  • the uplink service routing policy is designed as a specific structure of the device management resource ⁇ mgmtObj>.
  • the mgmtDefinition attribute value of the ⁇ mgmtObj> resource needs to be set.
  • the uplink service routing policy such as nsRoutePolicyUplink
  • other service configuration messages such as the creation of an uplink service routing policy resource ⁇ nsRoutePolicyUplink> on the ASN-CSE
  • the IN-CSE may trigger the AE or CSE on the terminal device to perform the service re-registration process described in step 412 through the configuration message or an independent trigger message.
  • the configuration message is a registration response message
  • the registration response message may carry re-registration indication parameters (such as a special HTTP 300 series redirection response code, or an extended message header, message body content, etc.);
  • the configuration message is a device management command
  • the command needs to access a specific ⁇ mgmtObj> resource (which can be an extension of an existing ⁇ mgmtObj> resource or a new type of ⁇ mgmtObj> resource), which includes re-registration Indicates the attribute re-registration, or further includes related network slice information (such as a network slice identifier or a link to the above-mentioned service routing policy resource or attribute containing the network slice information).
  • the IN-CSE will request the underlying 3GPP network to configure the relevant network slice subscription data for the terminal device, which may specifically be implemented by interacting with the UDM / UDR directly or through the NEF API, as shown in step 411.
  • the terminal device selects to access the network slice in the policy according to the uplink service routing policy configured in step 410, and the AE or CSE on the terminal device passes the new network slice according to the conditions in the uplink service routing policy.
  • the registration message needs to carry the necessary information of the new network slice (such as the identity of the new network slice, the AE on the terminal device or the addressing information of the CSE in the new network slice (such as the identity, IP Address, access point (Point of Access, PoA, etc.), and / or network element address in the new slice, etc.).
  • AEs on the terminal equipment belong to the source or destination of different service flows, they need to register to the IN-CSE through different network slices; or when CSE is deployed on the terminal equipment, the AE only registers with the local CSE.
  • the CSE (representing one or more AEs) performs multiple registrations with the IN-CSE through multiple network slices.
  • the AE or CSE on the terminal device can select one of multiple network slices to register with the IN-CSE, but the registration message needs to carry all necessary information about the relevant network slice (such as the network slice identification, AE on the terminal device) Or the addressing information of the CSE in each network slice (such as identification, IP address, Point of Access (PoA), etc.), and / or slice network element address, etc.).
  • the terminal device may need to further interact with the network to obtain the above-mentioned terminal device addressing information or slice network element address information.
  • the terminal device when the terminal device is under a firewall / gateway, it needs to obtain its public network address through methods such as STUN, and Ensure that the firewall / gateway can keep its public network address accessible by the communication peer (IN-CSE) that has not yet established a connection.
  • I-CSE communication peer
  • the terminal device does not need to perform this step.
  • the platform may obtain supplementary information of the sliced network element (such as the current service UPF or NEF address of the terminal device) from the registration message, thereby further refreshing the downlink service routing policy generated in step 408.
  • the terminal device When the terminal device sends an uplink service message, it determines the service characteristics of the service message (such as one of the source, destination, resource type, message type, operation method, and message priority) according to the uplink service routing policy shown in Table 7. Multiple) corresponding network slices, and send uplink service messages through the network slices.
  • the service characteristics of the service message such as one of the source, destination, resource type, message type, operation method, and message priority
  • IN-CSE receives a downlink service message from an IN-AE (the application identifier is IN-AE2), for example, the message is used to read a temperature sensor value on the terminal device;
  • the IN-CSE extracts the service characteristics of the downlink service message, including the resource whose destination address is a ⁇ flexContainer> type on the terminal device, the operation method is read (R), and it does not carry a specific message priority indication .
  • the IN-CE queries the downlink service routing strategy as shown in Table 3. According to the fourth record, the IN-CSE selects the mMTC-C network slice through the VDF to prepare to send the downlink service message to the terminal device.
  • IN-CSE judges that the downlink service message is an ordinary user plane message, and then chooses to send the downlink service message to the terminal device through the UPF2 network element of the mMTC-C slice, so the message is forwarded to UPF2. address. If, in another possible embodiment, the IN-CSE determines that the downlink message needs to call the NEF API (for example, it needs to know the sleep status of the terminal device through the NEF API or send an MBMS multicast message through the NEF), it needs to Forward the downlink message to NEF2, or call related API capabilities of NEF2 before forwarding the downlink message to UPF2 according to the requirements of the business process.
  • the NEF API for example, it needs to know the sleep status of the terminal device through the NEF API or send an MBMS multicast message through the NEF
  • business scenario a that is, the mode in which industry applications directly contract to the underlying network operator to purchase network slicing services
  • business scenario b that is, the mode in which industry applications directly contract to the underlying network operator to purchase network slicing services
  • the method shown in FIG. 3 It can be further supplemented and refined into the method flow shown in FIG. 5.
  • the difference between the method flow shown in FIG. 5 and the method flow shown in FIG. 4 lies in how the IoT platform obtains information about service characteristics and corresponding network slices.
  • Step 501 since the industry application has directly signed a contract with a network operator to purchase a network slicing service, in this scenario, the information of the network slicing and the business feature information related to the slicing have been performed on the industry application in advance After configuration (see step 501), the platform only needs to obtain the information from industry applications (see step 502), so as to establish (and store) a service routing policy.
  • Steps 503 to 513 in FIG. 5 are the same as steps 406 to 416 in FIG. 4, and details are not described herein again.
  • the method flow shown in FIG. 5 can also be implemented using multiple methods or protocol architectures. Taking the oneM2M standard protocol framework as an example, one possible specific implementation of the method flow shown in FIG. 5 is:
  • the network slice information includes: slice identifier / name (such as S-NSSAI, NS-ID), slice type (such as eMBB, uRLLC, mMTC) operator identifier / name (such as CMCC, VDF), and slice network element address (such as One or more of the IP addresses of the UPF and NEF, and the VLAN ID or tunnel ID of the IN-CSE to establish a transport layer connection with the UPF / NEF); the service characteristic information related to the slice includes: source / destination application identifier (Such as APP-ID, AE-ID), source / destination middleware identifier (such as CSE-ID), business resource identifier (such as Resource-ID), business resource type (such as group, container, mgmtObj type), and business message type (Such as request req or response resp) or operation method (such as create C / get R / update U / delete D /
  • slice identifier / name such as S-NSSAI, NS-
  • the IN-AE sends a message to the IN-CSE to configure a service routing policy.
  • This message can be a registration message sent by IN-AE to IN-CSE, such as the creation of an ⁇ AE> resource message; it can also be a separate configuration message, such as the creation of an independent service routing policy resource ⁇ nsRoutePolicy>, or the creation or update of a service Contract resource ⁇ serviceSubscriptionProfile>, etc.
  • the above message will carry the pre-configured network slice information and service feature information related to the slice described in step 1, and the way of carrying it may be a resource attribute or a sub-resource.
  • the IN-AE can carry the downlink service routing policy as shown in Table 6 configured for the IN-CSE for the IN-CSE to make service routing selection for the downstream service flow sent to the terminal device. It can also carry The uplink service routing policy as shown in Table 7 configured for one or more terminal devices is used for the terminal device to make service routing selection for the uplink service flow sent to the IN-CSE.
  • Steps 503-513 can be implemented in the same specific implementation manner as the method and process shown in FIG. 4, and details are not described herein again.
  • business scenario c there is also a possible business scenario c.
  • the platform can obtain network slice information and corresponding service feature information from the terminal device.
  • the method flow shown in 3 can be further supplemented and refined into the method flow shown in FIG. 6.
  • the terminal device is pre-configured with information about network slices and service features related to the slices, and the information and service features of the network slices are similar to those described in service scenarios a and b.
  • the difference is that each terminal device is only configured with the above-mentioned information related to itself, while the industry applications and the underlying network in business scenarios a and b are configured with the platform with the above-mentioned information of all terminal devices related to the industry application.
  • the information of the network slice and the service characteristics related to the slice can be pre-configured in the AE or CSE on the terminal device.
  • the terminal device accesses the network slice corresponding to the service characteristics according to the standard procedure of 3GPP, establishes a data channel with the network, and obtains an IP address.
  • the terminal device initiates a process for configuring a service routing policy to the platform through the network slice accessed in step 602, and sends the information about the network slice and service characteristics related to the slice to the platform.
  • This process can be part of the terminal device's registration process with the platform (that is, implemented through the terminal device's registration request message with the platform), or it can be an independent process (such as through a separate configuration message).
  • the terminal device accesses multiple network slices at the same time, the information may be sent to the platform through one of the network slices, or the information related to the network slice may be sent separately through each network slice.
  • the method When the method is implemented through the oneM2M standard framework, it can be a registration message sent by the AE or CSE on the terminal device to the IN-CSE, such as the creation of a ⁇ AE> resource message, or a separate configuration message, such as the creation of an independent service Routing policy resource ⁇ nsRoutePolicy>, or create or update a service subscription resource ⁇ serviceSubscriptionProfile>, etc.
  • the 603 message may only carry the downlink service routing policy related to the terminal device.
  • the uplink / downlink service routing policy of the terminal device is completely determined by its own configuration, and industry applications may not have the right to configure the uplink / downlink service routing policy for the terminal device through the platform.
  • the platform may need to combine Figure 4 and The method flow shown in FIG. 6 matches the service level requirements of industry applications with the service level service capabilities that can be provided by the network slice actually connected to the terminal device, as shown in FIG. 7.
  • the terminal device accesses the corresponding network slice according to the pre-configured network slice information and the service characteristics related to the slice, and also configures the relevant downstream service routing policy to the platform. ;
  • the industry application sends a service feature and a service level requirement (SLA) related to the service feature information to the platform.
  • SLA service level requirement
  • the platform checks whether the network slice accessed by the terminal device described in steps 701-703 can match (or meet) the service level requirements (such as bandwidth, delay, reliability, etc.) described in step 704. It should be noted that the platform can obtain the performance parameters (such as bandwidth, delay, reliability, and other performance) of the network slice through query or local storage. For example, in step 701, the downlink service routing policy configured by the terminal device requires that all downlink messages must use eMBB, and the slice cannot meet the downstream message delay requirements of the industry application, which is considered to be mismatched.
  • the service level requirements such as bandwidth, delay, reliability, etc.
  • the subsequent steps are performed; if there is no match, an error response message is sent to the industry application and the subsequent steps are stopped; if there is only a partial match, it can be handled as a mismatch (send an error to the industry application and stop the subsequent steps) ; You can also perform the subsequent steps only for the matching parts and ignore the non-matching parts; or further select the non-matching parts that have the closest service level requirements or create network slices that match the service level requirements before performing the subsequent steps.
  • the platform creates a new network slice to meet the service level requirements of industry applications, the platform also needs to notify the terminal device to access the new network slice, as described in steps 409-412.
  • the technical solution proposed in this application enables the platform and terminal to be correct and effective by establishing a service routing policy on the platform and terminal.
  • the service routing of uplink and downlink service messages is performed, which solves the problem that the platform or terminal cannot select the correct slice for message forwarding and filtering for service flows with different characteristics, and simplifies the management of network slices for industry users.
  • the functions of the terminal device, industry application, or IoT platform described in this application can be implemented by independent devices or servers; the industry application or IoT platform can also be business logic functions deployed or running on the cloud or other general-purpose servers Or computer program.
  • the functions of a terminal device, an industrial application, or an Internet of Things platform can all be implemented by a device as shown in FIG. 8.
  • the apparatus 800 shown in FIG. 8 includes at least one processor 801, a communication line 802, a memory 803, and at least one communication interface 804.
  • the device 800 may be a terminal device, or an IoT platform or an industrial application device itself, or a chip in the terminal device, the IoT platform, or an industrial application device, which is not specifically limited in the embodiment of the present application.
  • the function / implementation process of the communication interface 804 can also be implemented through pins or circuits, etc .; optionally, the memory is a storage unit in the chip, such as a register, The storage unit may also be a storage unit located outside the chip in the terminal.
  • the processor 801 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more processors for controlling the execution of the program of the solution of the present application. integrated circuit.
  • CPU central processing unit
  • ASIC application-specific integrated circuit
  • the communication line 802 may include one or more paths for transmitting information between the aforementioned components.
  • the communication interface 804 is any type of device that implements signal transmission and reception, and is used to communicate with other devices or devices or communication networks, such as Ethernet, radio access network (RAN), and wireless local area networks. WLAN) and so on.
  • devices or devices or communication networks such as Ethernet, radio access network (RAN), and wireless local area networks. WLAN) and so on.
  • the memory 803 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type that can store information and instructions Dynamic storage device, can also be electrically erasable programmable read-only memory (electrically erasable programmable read-only memory (EEPROM)), read-only compact disc (compact disc-read-only memory (CD-ROM) or other optical disc storage, optical disc storage (Including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), disk storage media or other magnetic storage devices, or can be used to carry or store desired program code in the form of instructions or data structures and can be used by a computer Any other media accessed, but not limited to this.
  • the memory may exist independently and be connected to the processor through a bus. The memory can also be integrated with the processor.
  • the memory 803 is configured to store application program code that executes the solution of the present application, and is controlled and executed by the processor 801.
  • the processor 801 is configured to execute application program code stored in the memory 803, so as to implement functions of a terminal device, an industrial application, or an Internet of Things platform in the method of the present patent.
  • the processor 801 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 8.
  • the apparatus 800 may include multiple processors, such as the processor 801 and the processor 808 in FIG. 8. Each of these processors can be a single-CPU processor or a multi-CPU processor.
  • a processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).
  • the apparatus 800 may further include an output device 805 and an input device 806.
  • the output device 805 communicates with the processor 801 and can display information in a variety of ways.
  • the output device 805 may be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. Wait.
  • the input device 806 communicates with the processor 801 and can accept user input in a variety of ways.
  • the input device 806 may be a mouse, a keyboard, a touch screen device, or a sensing device.
  • the above-mentioned device 800 may be a general-purpose device or a special-purpose device.
  • the apparatus 800 may be a desktop computer, a portable computer, a dedicated server, a communication device, an embedded device, or a device having a similar structure in FIG. 8.
  • the application does not limit the type of the device 800.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.
  • the computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be from a website site, a computer, a server, or a data center.
  • the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, a data center, or the like that includes one or more available medium integration.
  • the available medium may be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk (Solid State Disk (SSD)), and the like.

Abstract

本申请提供一种物联网业务路由的方法，通过在物联网平台建立业务特征与网络切片的映射关系，或建立根据业务特征确定网络切片的路由策略，使得物联网平台能够根据行业应用发送的业务消息的业务特征，选择合适的网络切片向终端设备发送业务消息，以满足行业应用的多种网络需求。

Description

一种物联网业务路由的方法
本申请要求于2018年6月20日提交中国国家知识产权局、申请号为201810637157.3、发明名称为“一种物联网业务路由的方法”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信领域，尤其涉及一种物联网业务路由的方法、装置和系统。
背景技术
第三代合作伙伴计划(3rd Generation Partnership Project，3GPP)标准组织制定的下一代移动通信网络架构(即5G网络架构)中，物理网络可以被抽象划分成多个网络切片，每个网络切片构成一个端到端的逻辑网络，彼此之间逻辑上是隔离的。每个切片可以按照需求方的要求灵活地提供一种或多种网络服务，并且和网络中的其它切片互不影响。
为了支持客户的各类业务，比如以高清视频和虚拟现实为代表的增强移动宽带(Enhanced Mobile Broadband，eMBB)类业务，以自动驾驶和工业制造为代表的超可靠低时延通信(Ultra-reliable and Low-latency Communications，uRLLC)，以智能抄表为代表的大规模机器通信(Massive Machine Type Communications，mMTC)业务等，运营商会为每一类业务创建一个或多个网络切片。
在物联网时代，单个行业应用往往需要使用多个网络切片，单一的网络切片难以满足不同的业务需求。比如车联网业务中即需要uRLLC切片以保证自动驾驶时的高可靠低时延通信需求，同时也需要eMBB切片的以保障车载信息娱乐等大带宽通信需求；类似的，在能源和智慧城市等领域，即需要mMTC切片以支持海量的抄表业务，也需要uRLLC切片以支持实时可靠的管网线路监控来避免灾害。
进一步的，在典型的物联网系统部署中，多个行业应用可能通过一个统一的物联网平台(或简称平台)对终端设备进行管理或访问终端设备相关的业务数据，平台和终端设备之间则通过运营商的一个或多个网络切片相连。因此，也存在单个平台同时使用多个网络切片的需求。
虽然3GPP定义的5G网络架构允许一个终端设备同时接入和使用多个网络切片，然而限定了终端设备接入不同的网络切片要使用不同的应用标识，即一个应用相关的业务消息只能使用单一的网络切片进行消息传输，不能满足单一行业应用使用多个网络切片进行通信的需求；另外，现有技术也没有解决行业应用或物联网平台如何选择合适的网络切片与终端设备进行下行通信的问题。
发明内容
本申请实施例提供一种物联网业务路由的方法，通过在物联网平台建立业务特征与网络 切片的映射关系，或建立根据业务特征确定网络切片的路由策略，使得物联网平台(或简称平台)能够根据行业应用发送的业务消息的业务特征，选择合适的网络切片与终端设备进行通信，以满足行业应用的多种网络需求。
物联网平台可以从行业应用、UE或底层网络中获取网络切片信息(包括切片标识和/或切片网元地址)以及与切片相关的业务特征。比如，当行业应用的提供商或运营商事先已与网络运营商直接签约购买网络切片服务时，网络切片信息以及与切片相关的业务特征提前配置在行业应用或者终端设备上，进而通过行业应用或者终端设备的注册或者配置消息，将网络切片信息以及与切片相关的业务特征发送到平台；或者当行业应用的提供商或运营商事先没有与网络运营商签约购买网络切片服务时，物联网平台可以首先从行业应用获取业务等级需求和业务特征描述，然后根据业务等级需求向底层网络运营商购买网络切片服务、创建网络切片并获取网络切片信息。通过这种方式，物联网平台建立网络切片和业务特征间的映射关系，也相当于建立了根据业务特征确定网络切片的业务路由策略，该业务路由策略规定了不同特征的业务消息应该从哪个网络切片下发到终端设备，从而保证了不同业务消息在行业应用和终端设备间传输的业务等级需求。
当物联网平台接收到行业应用向终端设备发送的业务消息时，物联网平台解析所述业务消息中的业务特征，与所存储的业务路由策略进行匹配，从而选择与业务特征对应的网络切片向终端设备发送业务消息。
可选的，物联网平台还可以为终端设备建立业务路由策略，并下发到终端设备。终端设备存储收到的业务路由策略，并在发送业务消息时，根据业务消息的业务特征选择相应的网络切片发送业务消息。物联网平台向终端设备下发业务路由策略的实现方式可以有多种，比如在终端设备的业务注册响应消息下发、或通过设备管理命令下发、或通过专门的业务配置消息下发、或通过网络能力开放API下发、或通过嵌入式用户身份模块(Embedded-Subscriber Identity Module，eSIM)下发等。
可选的，与切片相关的业务特征可以包括允许或禁止通过特定切片发送的业务特征，以实现网络切片资源和流量的管理，避免网络切片资源被非必要的(如非授权的、不相干的、恶意的)业务流滥用，实现物联网平台对特定网络切片业务流的过滤控制。
本申请所提出的物联网业务路由的方法，涉及物联网平台，行业应用服务器，终端设备等装置。因此，本申请还提供实现上述物联网业务路由方法的装置。
另外，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述物联网业务路由的方法。
最后，本申请提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述物联网业务路由的方法。
附图说明
图1为本申请所适用的物联网系统架构；
图2为本申请所适用的一种基于3GPP网络的物联网系统架构；
图3为本发明实施例提供的一种物联网业务路由方法概要流程图；
图4为本发明实施例提供的一种行业应用通过物联网平台管理网络切片的场景下，物联网业务路由方法流程图；
图5为本发明实施例提供的一种物联网平台从行业应用获得网络切片信息的场景下，物联网业务路由方法流程图；
图6为本发明实施例提供的一种物联网平台从终端设备获得网络切片信息的场景下，物联网业务路由方法流程图；
图7为本发明实施例提供的另一种物联网业务路由方法流程图；
图8为本发明实施例提供的一种装置示意图。
具体实施方式
图1所示为本申请实施例所涉及的一种物联网系统架构，包括行业应用(指为特定行业提供服务的应用,或在特定场景或环境下提供服务的应用，如智能家居，车联网，工业制造和智慧城市等)、物联网平台(或简称平台)、底层网络和终端设备；其中，行业应用通过平台与终端设备进行通信，平台和终端设备通过底层网络进行连接和通信，终端设备可以通过多种连接方式(如有线或无线接入)和接入协议(如WIFI，ZigBee，蓝牙，窄带物联网(Narrow Band Internet of Things,NB-IoT)，5G等)接入底层网络，本发明实施例不进行限定。所谓底层网络，指相对行业应用所处的应用层来讲，处于协议栈较底层的传输网络，只要能实现平台与终端设备间通信的网络，都可以称之为底层网络。底层网络可以被划分为多个网络切片(或虚拟网络)，每一个网络切片根据网络需求(比如时延、带宽、安全性和可靠性等)进行划分,在不同的业务场景下，平台和终端设备使用与网络需求匹配的网络切片进行通信。
当本发明实施例中的底层网络为3GPP定义的5G网络时，图1所示的系统架构可以进一步细化为图2所示的系统架构。其中，3GPP网络中提供网络切片以及基于网络切片的通信服务，如经过用户面功能(user plane function，UPF)的通信和经过网络开放功能(network exposure function，NEF)的通信，3GPP网络还提供网络切片管理功能，如经过网络切片管理功能(network slice management function，NSMF)进行网络切片的创建、信息查询等。3GPP网络中还包括无线接入网络(radio access network，RAN)，接入管理功能(access management function，AMF)，和策略控制功能(policy control function，PCF)等3GPP标准定义的网元，此处不再赘述。根据网络部署的需要，上述网元在一个网络切片中可以有零个、一个或多个实例。
在图1和图2所示系统架构的基础上，以图3为例，对本申请实施例所提供的方法进行简要的概述，旨在使读者对本申请实施例中所述的方法有一个初步的了解。
301.平台获取网络切片的信息和与所述网络切片对应的业务特征。需要说明的是，不同的业务场景下，平台可能通过不同的方式获取网络切片信息和与所述网络切片对应的业务特征。
业务场景a.行业应用的提供商或运营商通过平台管理网络切片：该业务场景下，行业应 用的提供商或运营商不会直接向底层网络运营商购买网络切片服务，行业应用向平台发送业务等级需求(service level agreement，SLA)，平台根据行业应用的SLA需求向底层网络运营商购买网络切片服务、创建网络切片，使得行业应用和终端设备能够通过与SLA匹配的网络切片进行通信。具体的，
301a1.行业应用将其所需的SLA和业务特征发送给平台。SLA可以理解为行业应用所需要的、为满足一个或多个特征的业务流传输所需的服务质量(quality of service,QoS)和服务能力需求，包括但不限于带宽、时延、抖动、可靠性、隔离性、移动性、休眠周期、缓存大小、位置区域、漫游能力、是否同步等一个或多个方面的参数。在一个具体实现中，所述SLA可以通过上述参数列表的形式发送给平台，也可以在平台中预先设置若干基于上述参数列表的配置选项(Profile)，由行业应用进行选择(如发送配置选项的标识或类型)。本申请中所述业务特征包括但不限于源/目的应用标识、源/目的中间件标识、资源标识或类型、消息类型(请求/响应)或操作方法(如RESTful API调用中常见的C/R/U/D/N操作，代表创建或获取或更新或删除或通知等操作)、消息优先级等一个或多个特征。
301a2.平台根据SLA为行业应用选择已有的网络切片或创建新的网络切片。比如当与平台连接的现有一个或多个网络切片中，存在能够满足所述SLA的网络切片时，则平台可以选择满足所述SLA的网络切片为该行业应用服务。如果尚不存在满足所述SLA的网络切片(比如不满足时延或带宽的要求等)，则平台需要与底层网络交互，请求底层网络创建满足SLA要求的新的网络切片(如以图2为例，请求NSMF创建网络切片)，并获得所述新网络切片的信息(如以图2为例，从NSMF获取网络切片的信息)，并与新创建的网络切片建立连接(如以图2为例，建立与UPF和NEF的连接)，所述建立连接包括建立相关的传送网/链路层通道(如建立隧道、VLAN等)、网络层安全连接等。当所述SLA的描述与底层网络创建网络切片所需的输入参数(即切片模板)不一致时，平台还需要先将SLA的描述映射转换为切片模板，然后再请求底层网络创建所述新网络切片。需要说明的是，本申请中所述网络切片的信息，包括但不限于网络切片标识，网络切片名称，网络切片类型，运营商标识或名称，网络切片的网元地址(包括IP地址和传输层信息)等一个或多个信息。
业务场景b.行业应用直接向底层网络运营商购买网络切片服务，购买的网络切片的信息和与所述网络切片对应的业务特征已提前配置在行业应用中：
301b1.行业应用将购买的网络切片的信息和与所述网络切片对应的业务特征发送到平台，平台建立与所述网络切片的连接(如以图2为例，建立与UPF和NEF的连接)。
业务场景c.与业务场景b类似，行业应用直接向底层网络运营商购买网络切片服务，与业务场景b的不同点在于，行业应用购买的网络切片的信息和与所述网络切片对应的业务特征已提前配置在终端设备中：
301c1.终端设备将行业应用购买的网络切片的信息和与所述网络切片对应的业务特征发送到平台，平台建立与所述网络切片的连接(如以图2为例，建立与UPF和NEF的连接)。
需要说明的是，平台在301a2,301b1或301c1步骤中获取网络切片的信息后，还可以根据网络切片的信息是否完整，选择向底层网络进一步获取网络切片的补充信息，如图中301a3,301b2,301c2步骤。比如301a2,301b1或301c1步骤中只提供了网络切片的名称或标 识，但没有提供网络切片中必要的网元地址和相关传输层信息(如隧道标识、VLAN-ID等)；或者只提供了部分网元地址信息(如UPF地址)，但没有提供其余网元地址信息(如NEF地址)，则平台可以向底层网络发起网络切片信息查询请求(如以图2为例，向NSMF查询)，根据网络切片的名称/标识/部分网元地址信息，获得所需的网元地址信息和相关传输通道信息。
通过301步骤，平台记录了网络切片和业务特征间的对应关系，如表一所示，即通过业务特征可以确定对应的网络切片及网络切片的信息，或通过网络切片的信息可以确定对应的业务特征，相当于建立了根据业务特征选择网络切片的业务路由策略。业务路由策略还可以进一步细化为上行业务路由策略和下行业务路由策略，其中上行业务路由策略可以发送给终端设备(见305步骤)，下行业务路由策略由平台使用，平台根据下行业务路由策略选择网络切片发送下行业务消息。
表一、业务路由策略(即网络切片和业务特征间的对应关系)
Figure PCTCN2019091448-appb-000001
302.平台接收行业应用发往终端设备的下行业务消息。
303.平台解析下行业务消息，获取业务消息中的业务特征，确定与所述业务特征对应的网络切片，即目标网络切片。
304.平台通过目标网络切片向终端设备发送业务消息。
305.可选的，在a和b两种业务场景下，平台还可以在获得网络切片的信息和业务特征间的对应关系后，向终端设备发送网络切片的信息和与所述网络切片对应的业务特征，以使终端设备建立上行业务路由策略，即记录网络切片和与所述网络切片对应的业务特征。需要说明的是，网络切片信息和对应的业务特征不一定要同时发送给终端设备，物联网平台也可以在305消息中只包含终端设备要接入的网络切片，而不包含业务特征信息，或在其它的消息中再向终端设备下发网络切片信息对应的业务特征。后续终端设备在向平台和行业应用发送上行业务消息时，根据物联网平台下发的网络切片信息，选择合适的网络切片发送上行业务消息。本申请不限定305步骤和302、303、304步骤的先后关系。
可见，本申请实施例所提供的方案，不仅可以使同一行业应用使用不同的网络切片与终 端设备进行通信，还可以使终端或平台根据业务特征这样的业务层参数和粒度进行网络切片的选择，满足了行业应用或终端根据消息类型、访问的数据资源等灵活使用网络切片的需求。
需要说明的是，如上所述的与网络切片对应的业务特征还可以进一步划分为允许的业务特征和禁止的业务特征(如表二所示)，以实现网络切片资源和流量的管理，避免网络切片资源被非必要的(如非授权的、不相干的、恶意的)业务流滥用，实现物联网平台对特定网络切片业务流的过滤控制。比如，平台在第303步骤获得业务特征后，首选确定该业务特征是禁止的业务特征还是允许的业务特征，如果是禁止的业务特征，则平台不会通过该业务特征对应的网络切片发送下行消息，即不会执行304步骤，如果是允许的业务特征，平台才会执行304步骤。
表二、业务路由策略(即网络切片和业务特征间的对应关系)
Figure PCTCN2019091448-appb-000002
下面，基于图3所示的概要方法流程，针对不同的业务场景或业务场景场景，对本申请所提出的方案进行进一步细化的描述和介绍。
图3所示的概要方法流程，在业务场景a下，可以进一步补充和细化为如图4所示的方法流程。
401.与301a1相同，不再赘述。
402.可选的，平台可以查询底层网络中是否已经存在能够满足步骤1中所述的业务等级需求的网络切片。若是，则平台将从中选择一个或多个满足条件的网络切片为该行业应用(以及与之相关的终端设备)服务，并跳过步骤403-405。若否，比如所述业务等级需求中要求业务流的传输需要与其他行业应用相隔离，或者时延/带宽等参数达不到要求，则意味着需要创建新的网络切片来服务于该业务流，因此将执行步骤403-405。
403.平台向底层网络(如NSMF)请求创建满足业务等级需求的网络切片，请求中包括步骤401中所述业务等级需求对应的描述参数。当所述描述参数与网络切片管理器所能接受的描述参数(切片模板)不同时，平台还需要做相应的映射或转换，包括但不限于：参数名称的映射、单位的转换、参数的分解(比如行业应用到终端设备的端到端时延减去行业应用到平台之间的时延，从而得到终端设备到平台之间的网络切片的时延)、参数的过滤(比如排除与 网络无关的业务消息并发数/频率)等。
404.底层网络根据步骤403中的请求，在底层网络中创建相应的网络切片。
405.与301a2步骤相似，平台从底层网络获得所创建的网络切片的信息。
406.与301a3步骤相似，当步骤405中所获得的网络切片信息不完整时，平台可以向底层网络进一步获取网络切片的补充信息。
407.平台建立与网络切片的连接。
408.根据步骤405-407中所获得的网络切片的信息，以及步骤401中获得的业务特征，平台生成相应的上下行业务路由策略，如表一或表二所示。
409.因行业应用尚未为终端设备配置网络切片的相关信息，终端设备将通过默认的网络切片注册到平台。本步骤可以发生在步骤401-408之前的任意时刻，即不依赖平台与行业应用以及底层网络之间的交互结果，与步骤401-408在时间顺序上相独立。
410.平台为终端设备配置上行业务路由策略，下发配置的方式可以有多种，包括通过终端设备的业务注册响应消息下发、通过设备管理命令下发、通过专门的业务配置消息下发、通过网络能力开放API下发、通过eSIM流程下发等。具体的：
当步骤401中的业务特征包含了与所述终端设备相关的信息(比如源/目的应用标识、源/目的中间件标识、资源标识可分别对应于终端设备上的应用、中间件、资源，或者直接包含终端设备的标识)，则平台可以据此判断需要为哪些终端设备配置相应的上行业务路由策略，从而进行410步骤的配置操作；此外，平台可能还需要与底层网络交互，为所述终端设备配置接入相关网络切片所需的签约数据，如411步骤所示，比如平台通过NEF或直接与底层网络的用户数据管理网元交互，配置允许终端设备接入网络切片的签约数据。
当步骤401中的行业应用提供的信息不足以确定终端设备是否与特定的网络切片相关时(比如业务特征仅包含消息优先级、类型，而不包含终端设备相关信息)，平台可以暂时不执行本步骤，而是等到步骤414后，根据步骤414中的发往该终端设备的下行业务消息的业务特征来确定所述终端设备应该接入的网络切片，进而进行本步骤中所述的为终端设备配置上行业务路由策略的操作，以及411步骤为终端设备配置接入相关网络切片所需的签约数据的操作。
需要说明的是，物联网平台在410消息中可能只包含终端设备需要接入的网络切片的信息，与网络切片对应的业务特征可以不发送给终端设备，或在其它消息中发送给终端设备。410消息可能为配置消息或独立的触发消息。平台可以通过该配置消息或者独立的触发消息来触发终端设备执行步骤412中所述的重注册流程。
412.终端设备根据步骤410所配置的上行业务路由策略，选择接入所述策略中的网络切片，并通过新的网络切片重新注册到平台。若所述策略中的网络切片正好是终端设备在步骤409中所使用的默认网络切片，则终端设备不必执行本步骤。若终端设备需要同时接入多个网络切片时，可以通过每一个网络切片分别重新注册到平台一次，也可以进一步优化选择其中一个网络切片来一次性完成所有网络切片相关的重新注册(其中携带其它网络切片的必要信息，如终端设备在各网络切片中的寻址信息(如标识，IP地址，接入点(Point of Access， PoA)等)等)，如终端设备在409步骤通过默认网络切片注册，在412步骤再次通过默认网络切片重新注册，重新注册请求中包含终端设备在其它网络切片中的信息。当终端设备完成重新注册后，平台可以从所述注册消息中获得切片网元的补充信息(比如当前为终端设备服务的UPF或NEF地址)，进一步将这些信息补充到步骤408中所生成的下行业务路由策略中。
413.终端接入网络切片后，后续就可以根据410步骤中配置的上行业务路由策略，以及上行业务消息的业务特征，选择对应的网络切片，发送上行业务消息。
414-416.同302-304，此处不再赘述。
本申请所提供的方法可以使用多种方式来开发实现，如图4所示的方法流程可以以oneM2M标准为框架来实现。架构上，物联网平台对应oneM2M标准定义的IN-CSE(Common Services Entity resides in Infrastructure Node)，行业应用对应oneM2M标准定义的IN-AE(Application Entity resides in Infrastructure Node)，针对终端设备业务处理能力的强弱或配置的高低，不同类型的终端设备可能对应oneM2M标准定义的MN(Middle Node)或ASN(Application Service Node)或ADN(Application Dedicated Node)，oneM2M标准定义的如上概念详见oneM2M标准规范“TS-0001_Functional_Architecture”，此处不再赘述。
依据3GPP 5G标准和oneM2M标准框架，图4中所示方法流程的一种可能的实现方式为：
401.该步骤所发送的消息，具体可以是IN-AE向IN-CSE发送的注册消息，如创建<AE>资源消息；也可以是单独的配置消息，如创建一个或多个业务特征资源<trafficChar>和一个或多个相关联的业务等级需求资源<SLA>，或者创建一个或多个同时包含业务特征和业务等级需求的复合资源<trafficSLA>，或者创建业务路由策略资源<nsRoutePolicy>(其中包含业务等级需求相关的属性或子资源)，或者创建或更新业务签约资源<serviceSubscriptionProfile>中与业务特征和业务等级需求相关的属性或子资源。业务特征包括：源/目的应用标识(如APP-ID，AE-ID)、源/目的中间件标识(如CSE-ID)、业务资源标识(如Resource-ID)、业务资源类型(如group,container,mgmtObj类型)、业务消息类型(如请求req或响应resp)或操作方法(如创建C/获取R/更新U/删除D/通知N等)、消息优先级(如扩展消息中的Event Category参数取值，或在消息中新增Flow Type标签)等中的一个或多个。该消息中携带业务特征以及业务等级需求的方式可以是资源属性或子资源。如通过IN-AE的注册消息发送，则需要对oneM2M中的<AE>资源做扩展，增加同时包含业务特征和业务等级需求的复合属性trafficSLA作为<AE>的属性，或增加复合资源<trafficSLA>作为<AE>的子资源，或者增加业务路由策略资源<nsRoutePolicy>作为<AE>的子资源。当然上述扩展的属性或子资源还可以作为其它资源的属性或子资源存在，并不影响本申请方案的实施效果。无论如何实现，IN-CSE所收到的信息将形成如表三所述的数据结构关系，其中没有提供具体数值的记录单元表示任意值匹配或者默认值匹配。
表三.业务特征以及与之相关的业务等级需求
Figure PCTCN2019091448-appb-000003
Figure PCTCN2019091448-appb-000004
在本发明中的另一种实施方式中，还可以将业务等级需求进行分类，从而形成若干可配置的分类或等级(比如Profile,Category,Level等)，如表四所示：
表四.业务等级需求分类
Figure PCTCN2019091448-appb-000005
表四中的信息本身可以作为单独的资源或属性存在，或者其他资源(如根资源<CSEBase>,业务签约资源<serviceSubscriptionProfile>,业务等级需求资源<SLA>)的一部分存在，并且可以预先配置在IN-CSE中，也可以由一个或多个IN-AE创建或更新。
基于表四，表三可以简化为表五的形式，并且相同的业务等级需求分类可以被不同的业务流所复用。相应的，在IN-AE发送的消息中，可以简化业务等级需求的描述方式，直接引用已定义的业务等级需求分类标识或类型(如Profile1)
表五.业务特征以及与之相关的业务等级需求
Figure PCTCN2019091448-appb-000006
402.IN-CSE根据步骤401中获得的业务等级需求中的隔离性需求判断该行业应用的某些业务流并不需要隔离，则查询3GPP网络中的现有网络切片是否已经存在能够满足这些业务流所对应的业务等级需求的网络切片。若是，则IN-CSE将从中选择一个或多个满足条件的网络切片为该业务流(以及与之相关的终端设备)服务。若否，比如所述业务等级需求中要求隔离，或者现有的网络切片的时延/带宽等参数达不到要求，则执行步骤403-405。
403.IN-CSE向网络切片管理器NSMF请求创建满足业务等级需求的网络切片，并在必要时对请求中的业务等级需求的描述参数进行映射或转换。比如：参数名称的映射(如latency转换为delay)、单位的转换(如ms转化s)、参数的分解(如IN-AE到终端设备的端到端时延减去IN-AE到IN-CSE的时延后，从而得到网络切片的时延)、参数的过滤(比如排除与网络无关的业务消息并发数/频率)等。
404.NSMF根据步骤403中的请求，在底层网络中创建相应的网络切片。
405.IN-CSE从NSMF获得所创建的网络切片的信息。所述网络切片的信息包括：切片标识/名称(如NS-NSSAI，NS-ID)、切片类型(如eMBB,uRLLC,mMTC)、运营商标识/名称(如CMCC,VDF)、切片网元地址(如UPF和NEF的IP地址，以及IN-CSE与UPF/NEF建立链路层连接的VLAN标识或隧道标识)等中的一个或多个。
406.当步骤405中所获得的网络切片的信息不完整(比如没有获得必要的切片网元地址)，则IN-CSE可以向3GPP网络中的网络切片管理功能NSMF请求获取该网络切片中相关网元的补充信息(比如该切片中的UPF和NEF地址，或还包括传输层信息和其他信息(比如切片类型等))。IN-CSE发往NSMF的请求消息中携带切片标识eMBB-A，并在响应中获得所需的切片网元地址：UPF3:{IP5}；{VLAN5},NEF3:{IP6}；{VLAN6}，切片类型:eMBB等。
当一个网络切片中同时存在多个相同功能的网元(如多个UPF或多个NEF)时，IN-CSE可能还需要(根据终端设备的相关标识，如IMSI,IMEI,External-ID等)从NSMF查询特定终端所归属的(或服务的)特定网元信息，并做区分记录(将不同终端设备的资源标识、应用标识、中间件标识等分成多条记录，分别对应不同的切片网元地址传输层信息)。或者，待后续终端设备与IN-CSE完成注册或其他业务消息交互之后，IN-CSE根据从哪个具体的网元 收到该终端设备的业务消息，来确定该终端设备所归属的(或服务的)网元信息。
进一步的，IN-CSE还可能需要根据部分切片网元信息查询同一切片中的其它网元信息，比如若405步骤只获得了某个切片中的UPF地址，而缺少NEF地址，则IN-CSE需要根据该UPF地址查询同一切片中关联的NEF地址，反之亦然。
407.IN-CSE检查自身与上述网络切片是否已建立连接，若否，则根据上述步骤中获得的网络切片的信息(具体为各切片网元地址和传输层信息)与各相关网络切片建立连接。比如IN-CSE需要分别于UPF1，UPF2，UPF3，NEF1，NEF2，NEF3建立链路层及IP层连接。
408.根据步骤405-406中所获得的网络切片的信息，以及步骤401中获得的业务特征，IN-CSE将生成相应的上下行业务路由策略，其具体内容与形式可参考表六和表七。根据具体实施方式的不同，还可以将表三、表四、表五与表六或表七进行合并。表六中的每一条记录都可以有一项或多项单元空缺。没有填写的记录单元表示任意值均匹配，或者采用默认值匹配。每条记录中的每个单元项可以填写多个信息，比如“源”和“目的”里可以填写多个CSE-ID，AE-ID,Resource-ID，“资源类型”里可以填写<container>,<group>等多种资源类型，其他单元项以此类推。为了区分每个网络切片允许或者禁止通过的业务流，可以单独建立一个与表六类似的属性或子资源(采用不同的名称或类型，比如nsRoutePolicyBlocked属性或<nsRoutePolicyBlocked>资源)，用来描述禁止通过的业务特征，则表六用来描述允许通过的业务特征。或者在表六中的相关单元项中增加额外的关联标签用来区分，比如第4条记录的“源”中的“IN-AE1”应用标识之后增加“；f”关联标签，表示IN-AE1被禁止作为发起方通过mMTC-C切片向终端设备发送业务消息。或者对整个<nsRoutePolicy>资源增添一个禁止或允许标记属性(如blocked＝true,或者allowed＝false，或者purpose＝block)用来区分。
表六.业务路由策略属性或子资源数据结构(下行)
Figure PCTCN2019091448-appb-000007
上行业务路由策略如表七所示，用于终端设备为发往IN-CSE的上行业务流做业务路由选择。表七中同样包括网络切片信息以及与切片相关的业务特征信息，区别在于，表七中的网络切片信息相对简单，可以不需要切片网元地址信息。当多个终端设备都需要配置上行业务 路由策略时，IN-CSE可以为每个终端设备单独创建相应的业务路由策略属性或业务路由策略资源，或者为它们创建共享的属性或资源，共享的方式可以通过关联链接指向同一个业务路由策略属性或资源来实现。
为了与下行业务路由策略属性或资源进行区分，可以为上行业务路由策略设计名称或类型不同的属性或资源，比如nsRoutePolicyUplink属性或<nsRoutePolicyUplink>资源。又或者，由于上下行业务路由策略的数据结构基本相同，二者可以共用同样的nsRoutePolicy属性或<nsRoutePolicy>资源类型，但通过在其中增加一个上下行标记属性来进行区分(如direction＝uplink or downlink)；同样的，上行业务路由策略中也可以用不同的名称或类型或者关联标签、标记属性等方法来区分允许或禁止通过的业务流。
表七.业务路由策略属性或子资源数据结构(上行)
Figure PCTCN2019091448-appb-000008
409.终端设备上的AE或CSE通过默认的网络切片注册到IN-CSE。
410.IN-CSE判断终端设备为首次注册(或判断终端设备的注册消息来自与步骤408中所生成的业务路由策略不同的网络切片)，则将步骤408中生成的上行业务路由策略配置到终端设备。配置下发的方式可以有多种，比如当终端设备上的AE或CSE向IN-CSE发起注册流程时，在其注册响应消息中下发(扩展消息体内容)；也可以通过单独的设备管理命令下发，为此则要将上行业务路由策略设计为一个设备管理资源<mgmtObj>的具体化结构，其中除了包含表七中的相关信息以外，还需要将<mgmtObj>资源的mgmtDefinition属性值设置为能够表示上行业务路由策略的值，如nsRoutePolicyUplink；类似的，还可以通过其它业务配置消息(如在ASN-CSE上创建上行业务路由策略资源<nsRoutePolicyUplink>)，或者通过eSIM远程发放流程来下方。进一步的，IN-CSE可以通过该配置消息或者独立的触发消息来触发终端设备上的AE或CSE执行步骤412中所述的业务重注册流程。比如所述配置消息为注册响应消息，则注册响应消息中可携带重注册指示参数(如一个特殊的HTTP的300系列的重定向响应码，或一个扩展的消息头、消息体内容等)；若所述配置消息为设备管理命令时，该命令需要访问一个特定的<mgmtObj>资源(可以是现有<mgmtObj>资源的扩展，或者新的<mgmtObj>资源的具体化类型)，其中包含重注册指示属性re-registration，或还包括相关网络切片信息(比如网络切片标识、或者指向包含了网络切片信息的上述业务路由策略资源或属性的链接等)。同时，IN-CSE将向底层3GPP网络请求为所述终端设备配置相关的网络切片签约数据，具体可以是直接或通过NEF API与UDM/UDR交互实现，如步骤411所示。
412.终端设备根据步骤410所配置的上行业务路由策略，选择接入所述策略中的网络切片，终端设备上的AE或CSE则根据所述上行业务路由策略中的条件，通过新的网络切片重新注册到IN-CSE，注册消息中需要携带新的网络切片的必要信息(比如新的网络切片的标识、终端设备上的AE或CSE在新的网络切片中的寻址信息(如标识，IP地址，接入点(Point of Access，PoA)等)、和/或新的切片中网元地址等)。比如终端设备上的不同AE若分别属于不同业务流的源或目的方，则需要分别通过不用的网络切片注册到IN-CSE；或者终端设备上部署有CSE时，AE仅向本地的CSE注册，而CSE则(代表一个或多个AE)通过多个网络切片向IN-CSE进行多次注册。
进一步的，终端设备上的AE或CSE可以选择多个网络切片中的一个注册到IN-CSE，但该注册消息中需要携带所有相关网络切片的必要信息(比如网络切片标识、终端设备上的AE或CSE在各网络切片中的寻址信息(如标识，IP地址，接入点(Point of Access，PoA)等)、和/或切片网元地址等)。为此终端设备可能还需要与网络进一步交互来获得上述终端设备寻址信息或切片网元地址信息，比如当终端设备处于防火墙/网关之下时，需要通过STUN等方法获得其公网地址，并确保防火墙/网关能够保持其公网地址可被尚未建立连接的通信对端(IN-CSE)所访问。
若所述策略中的网络切片正好是终端设备在步骤409中所使用的默认网络切片，则终端设备不必执行本步骤。当终端设备完成重新注册后，平台可以从所述注册消息中获得切片网元的补充信息(比如终端设备当前的服务UPF或NEF地址)，从而进一步刷新步骤408中所生成的下行业务路由策略。
413.终端设备在发送上行业务消息时，依据表七所示的上行业务路由策略，确定业务消息的业务特征(如源、目的、资源类型、消息类型、操作方法、消息优先级中的一个或多个)对应的网络切片，并通过该网络切片发送上行业务消息。
414.IN-CSE接收来自一个IN-AE(应用标识为IN-AE2)的下行业务消息，比如该消息用来读取终端设备上的一个温度传感器值；
415.IN-CSE提取所述下行业务消息的业务特征，其中包括目的地址为终端设备上的一个<flexContainer>类型的资源，操作方法为读取(R)，且没有携带特定的消息优先级指示。IN-CE查询如表三的下行业务路由策略，根据其中的第4条记录，IN-CSE选择通过VDF的mMTC-C网络切片，准备发送所述下行业务消息到终端设备。
416.IN-CSE判断所述下行业务消息是一个普通的用户面消息，则选择将所述下行业务消息经过mMTC-C切片的UPF2网元发送给终端设备，因此将所述消息转发给UPF2的地址。若在另一个可能的实施例中，IN-CSE判断所述下行消息需要调用NEF的API时(比如需要通过NEF的API获知终端设备的休眠状态，或者通过NEF发送MBMS多播消息)，则需要将所述下行消息转发到NEF2，或者根据业务流程的要求在转发所述下行消息到UPF2之前调用NEF2的相关API能力。
以上为业务场景a下，本申请所提供的方法及可能的实现方式，在业务场景b下，即行业应用直接向底层网络运营商签约购买网络切片服务的模式下，图3所示的方法，可以进一步补充和细化为如图5所示的方法流程。图5中所示方法流程与图4所示方法流程的区别点 在于物联网平台如何获得业务特征和对应的网络切片的信息。在图5所示的方法流程中，由于行业应用已与网络运营商直接签约购买网络切片服务的场景，该场景下，网络切片的信息以及与切片相关的业务特征信息已经事先在行业应用上进行了配置(见501步骤)，平台只需要从行业应用获取所述信息(见502步骤)，从而建立(并存储)业务路由策略。图5中的的503-513步骤与图4中的406-416步骤相同，这里不再赘述。
类似的，图5中所示的方法流程也可以使用多种方式或协议架构来实现，以oneM2M标准协议框架为例，图5中所示方法流程的一种可能的具体实现为：
501.IN-AE预先配置网络切片信息和与切片相关的业务特征信息。所述网络切片信息包括：切片标识/名称(如S-NSSAI，NS-ID)、切片类型(如eMBB,uRLLC,mMTC)运营商标识/名称(如CMCC,VDF)、切片网元地址(如UPF和NEF的IP地址，以及IN-CSE与UPF/NEF建立传输层连接的VLAN标识或隧道标识)等中的一个或多个；所述与切片相关的业务特征信息包括：源/目的应用标识(如APP-ID，AE-ID)、源/目的中间件标识(如CSE-ID)、业务资源标识(如Resource-ID)、业务资源类型(如group,container,mgmtObj类型)、业务消息类型(如请求req或响应resp)或操作方法(如创建C/获取R/更新U/删除D/通知N等)、消息优先级(如扩展消息中的Event Category参数取值，或在消息中新增Flow Type标签)等中的一个或多个。还包括针对每一个网络切片，将上述业务特征分为允许通过的和禁止通过的2类。
502.IN-AE向IN-CSE发送配置业务路由策略的消息。该消息可以是IN-AE向IN-CSE发送的注册消息，如创建<AE>资源消息；也可以是单独的配置消息，如创建一个独立的业务路由策略资源<nsRoutePolicy>，或者创建或更新业务签约资源<serviceSubscriptionProfile>等。上述消息中将携带步骤1中所述的预配置的网络切片信息和与切片相关的业务特征信息，并且携带的方式可以是资源属性或子资源。如通过IN-AE的注册消息发送，则需要对oneM2M中的<AE>资源做扩展，增加业务路由策略属性nsRoutePolicy作为<AE>的属性，或增加业务路由策略资源<nsRoutePolicy>作为IN-AE的子资源，其中包含如表六所示数据结构的一条或多条记录。在该步骤的消息中，IN-AE除了可以携带为IN-CSE配置的如表六的下行业务路由策略，用于IN-CSE为发往终端设备的下行业务流做业务路由选择，还可以携带为一个或多个终端设备配置的如表七的上行业务路由策略，用于终端设备为发往IN-CSE的上行业务流做业务路由选择。
503-513步骤可以采用与图4所示方法流程相同的具体实现方式，此处不再赘述。
如前所述，除了业务场景a和业务场景b之外，还存在一种可能的业务场景c，此种业务场景下，平台可以从终端设备获取网络切片的信息和对应的业务特征信息，图3所示的方法流程可以进一步补充和细化为如图6所示的方法流程。
601.终端设备预先配置了网络切片的信息和与切片相关的业务特征，所述网络切片的信息和业务特征与业务场景a和b中的描述类似。区别在于，每个终端设备仅配置与自身相关的上述信息，而业务场景a和b中的行业应用和底层网络向平台配置了与该行业应用相关的所有终端设备的上述信息。当通过oneM2M标准框架实现本方法时，可以在终端设备上的AE或CSE预先配置网络切片的信息和与切片相关的业务特征。
602.终端设备根据3GPP的标准流程接入与业务特征对应的网络切片，建立与网络的数 据通道和获取IP地址。
603.终端设备通过步骤602中所接入的网络切片，向平台发起配置业务路由策略的流程，将上述网络切片的信息和与切片相关的业务特征发送给平台。该流程可以是终端设备向平台注册流程中的一部分，(即通过终端设备向平台注册请求消息实现)，也可以是独立的流程(比如通过单独的配置消息等方式实现)。当终端设备同时接入了多个网络切片时，可以通过其中一个网络切片将所述信息发送给平台，也可以通过每个网络切片单独发送与该网络切片相关的所述信息。当通过oneM2M标准框架实现本方法时，可以是终端设备上的AE或CSE向IN-CSE发送的注册消息，如创建<AE>资源消息；也可以是单独的配置消息，如创建一个独立的业务路由策略资源<nsRoutePolicy>，或者创建或更新业务签约资源<serviceSubscriptionProfile>等。需要说明的是，603消息中可以只携带与终端设备相关的下行业务路由策略。
604-606.与图4中的406-408，或图5中的503-505类似，不同之处在于，平台不需要生成上行业务路由策略。
607-609.与图4中的414-416，或图5中的511-513相同。
需要说明的是，实际的业务场景可能比如上所述的业务场景a、b、c更为复杂，因此可能需要对如上各种业务场景下的方法流程进行一定的整合以适配更加复杂的业务场景。比如存在不同用户分别拥有行业应用和终端设备的运营权或产权的业务场景，如智慧灯杆上的传感器可能归属于某一政府部门，而传感器的数据(比如大气污染等)可能给环保的行业应用使用，即环保行业应用和智慧灯杆上的传感器所归属的用户不同。这种情况下，终端设备的上/下行业务路由策略完全由自身的配置所确定，而行业应用可能无权通过平台为终端设备配置上/下行业务路由策略，此时平台可能需要结合图4和图6中所示的方法流程，对行业应用的业务等级需求和终端设备实际所接入的网络切片能够提供的业务等级服务能力进行匹配，如图7中所示。
701-703.参考图6中所示601-603步骤，终端设备根据预先配置的网络切片的信息和与切片相关的业务特征，接入相应的网络切片，还将相关下行业务路由策略配置到平台；
704.参考图4中的步骤401，行业应用向平台发送业务特征以及与业务特征信息相关的业务等级需求(SLA)。
705.平台检查步骤701-703中所述终端设备接入的网络切片能否匹配(或满足)步骤704中所述的业务等级需求(比如带宽、时延、可靠性等)。需要说明的是，平台可以通过查询或本地存储的方式获取到网络切片的性能参数(如带宽、时延、可靠性等性能)。比如步骤701中，终端设备配置的下行业务路由策略要求所有下行消息都必须使用eMBB，而该切片不能满足行业应用的下行消息时延要求，则认为不匹配。若匹配，则执行后续步骤；若不匹配，则发送错误响应消息给行业应用，停止执行后续步骤；若只有部分匹配，则可以按不匹配处理(发送错误相应给行业应用，停止执行后续步骤)；也可以仅针对匹配的部分执行后续步骤，忽略不匹配的部分；或者进一步为不匹配的部分选择业务等级需求最接近的或者创建与业务等级需求匹配的网络切片，然后再执行后续步骤。当平台为了满足行业应用的业务等级需求创建了新的网络切片时，平台还需要通知终端设备接入新的网络切片，如409-412步骤所述。
706-711.与前各实施例相同，不再赘述。
通过如上具体实施方式可以看出，当物联网行业应用和终端设备需要使用多个网络切片时，本申请所提出的技术方案通过在平台和终端上建立业务路由策略，使得平台和终端能够正确有效地对上下行业务消息进行业务路由，解决了平台或终端无法为不同特征的业务流选择正确的切片进行消息转发和过滤的问题，并且为行业用户简化了网络切片的管理。
本申请中所述的终端设备、行业应用或物联网平台的功能可以由独立的装置或服务器来实现；行业应用或物联网平台还可以是部署或运行在云或其它通用服务器上的业务逻辑功能或计算机程序。比如，终端设备、行业应用或物联网平台的功能均可以通过如图8中所示装置来实现。图8所示的装置800包括至少一个处理器801，通信线路802，存储器803以及至少一个通信接口804。该装置800可以是终端设备、或物联网平台或行业应用装置本身，也可以是终端设备、物联网平台或行业应用装置内的芯片，本申请实施例对此不作具体限定。当该装置800是芯片时，可选的，通信接口804的功能/实现过程还可以通过管脚或电路等来实现；可选的，所述存储器为所述芯片内的存储单元，如寄存器、缓存等，所述存储单元还可以是所述终端内的位于所述芯片外部的存储单元。
处理器801可以是一个通用中央处理器(central processing unit，CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。
通信线路802可包括一个或多个通路，在上述组件之间传送信息。
通信接口804，实现信号收发的任何一类的装置，用于与其他设备或装置或通信网络通信，如以太网，无线接入网(radio access network，RAN)，无线局域网(wireless local area networks，WLAN)等。
存储器803可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
其中，存储器803用于存储执行本申请方案的应用程序代码，并由处理器801来控制执行。处理器801用于执行存储器803中存储的应用程序代码，从而实现本专利方法中终端设备、行业应用或物联网平台的功能。
在具体实现中，作为一种实施例，处理器801可以包括一个或多个CPU，例如图8中的CPU0和CPU1。
在具体实现中，作为一种实施例，装置800可以包括多个处理器，例如图8中的处理器801和处理器808。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处 理数据(例如计算机程序指令)的处理核。
在具体实现中，作为一种实施例，装置800还可以包括输出设备805和输入设备806。输出设备805和处理器801通信，可以以多种方式来显示信息。例如，输出设备805可以是液晶显示器(liquid crystal display，LCD),发光二级管(light emitting diode，LED)显示设备，阴极射线管(cathode ray tube，CRT)显示设备，或投影仪(projector)等。输入设备806和处理器801通信，可以以多种方式接受用户的输入。例如，输入设备806可以是鼠标、键盘、触摸屏设备或传感设备等。
上述的装置800可以是一个通用装置或者是一个专用装置。在具体实现中，装置800可以是台式机、便携式电脑、专用服务器、通信设备、嵌入式设备或有图8中类似结构的设备。本申请不限定装置800的类型。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
本领域技术人员应该理解的是，以上所述仅为本申请所提出技术方案的具体实施方式而已，并不用于限定本发明的保护范围，凡在本申请的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。在权利要求中，“包括”一词不排除其他组成部分或步骤，“一”或“一个”不排除多个的情况。单个处理器或其它单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施，但这并不表示这些措施不能结合起来产生良好的效果。

Claims (29)

  1. 一种物联网业务路由的方法，其特征在于，
    物联网平台接收来自应用的业务消息；
    所述物联网平台根据所述业务消息的业务特征，确定与所述业务特征对应的目标网络切片；
    所述物联网平台通过所述目标网络切片，向终端设备发送所述业务消息。
  2. 根据权利要求1所述的方法，其特征在于，所述物联网平台确定与所述业务特征对应的目标网络切片之前，所述方法还包括，
    所述物联网平台获取所述业务特征以及与所述业务特征对应的所述目标网络切片的信息。
  3. 根据权利要求2所述的方法，其特征在于，所述物联网平台获取所述业务特征以及与所述业务特征对应的所述目标网络切片的信息，具体包括，
    所述物联网平台从所述应用获取所述业务特征以及与所述业务特征对应的所述目标网络切片的信息。
  4. 根据权利要求2所述的方法，其特征在于，所述物联网平台获取所述业务特征以及与所述业务特征对应的所述目标网络切片的信息，具体包括，
    所述物联网平台从所述应用获取所述业务特征，及与所述业务特征对应的业务需求；
    所述物联网平台从底层网络获取与所述业务特征对应的所述目标网络切片的信息。
  5. 根据权利要求4所述的方法，其特征在于，所述物联网平台从底层网络获取与所述业务特征对应的所述目标网络切片的信息，具体包括，
    在所述底层网络中已经存在满足所述业务需求的网络切片的情况下，所述物联网平台从满足所述业务需求的网络切片中选择所述目标网络切片，并获取所述目标网络切片的信息。
  6. 根据权利要求4所述的方法，其特征在于，所述物联网平台从底层网络获取与所述业务特征对应的所述目标网络切片的信息，具体包括，
    在所述底层网络中不存在满足所述业务需求的网络切片的情况下，所述物联网平台请求所述底层网络创建满足所述业务需求的所述目标网络切片，并从所述底层网络获取所述目标网络切片的信息。
  7. 根据权利要求6所述的方法，其特征在于，所述物联网平台从所述应用获取的所述业务需求包括所述业务需求的描述参数，所述物联网平台请求所述底层网络创建满足所述业务需求的所述目标网络切片的消息中，包括所述目标网络切片的的描述参数，所述目标网络切片的的描述参数为所述物联网平台根据所述业务需求的描述参数经转换或映射而获得。
  8. 根据权利要求5-7任一所述的方法，其特征在于，所述方法还包括，所述物联网平台通过向所述底层网络查询的方式，判断是否存在满足所述业务需求的网络切片，并根据判断结果，执行如权利要求5或6所述的方法。
  9. 根据权利要求2-8任一所述的方法，其特征在于，所述物联网平台获取所述业务特征以及与所述业务特征对应的所述目标网络切片的信息之后，所述方法还包括，
    所述物联网平台根据所述业务特征以及与所述业务特征对应的所述目标网络切片的信息，确定与所述业务特征对应的上行业务消息的业务特征，以及与所述上行业务消息的业务特征对应的所述目标网络切片的信息，所述上行消息为所述终端设备发送的消息；
    所述物联网平台向所述终端设备发送所述上行业务消息的业务特征以及与所述上行业务消息的业务特征对应的所述目标网络切片的信息。
  10. 根据权利要求2-8任一所述的方法，其特征在于，所述物联网平台获取所述业务特征以及与所述业务特征对应的所述目标网络切片的信息之后，所述方法还包括，
    所述物联网平台向所述终端设备发送所述目标网络切片的信息。
  11. 根据权利要求1-8任一所述的方法，其特征在于，所述物联网平台通过所述目标网络切片，向终端设备发送所述业务消息之前，所述方法还包括，所述物联网平台与底层网络中的网元交互，向所述底层网络配置所述终端设备接入所述目标网络所需的签约数据。
  12. 根据权利要求1-11任一所述的方法，其特征在于，所述物联网平台通过所述目标网络切片，将所述业务消息发送至终端设备之前，所述方法还包括，
    所述物联网平台接收所述终端设备发送的注册请求，所述注册请求中包括所述终端设备在所述目标网络切片中的寻址信息；
    所述物联网平台通过所述目标网络切片，向终端设备发送所述业务消息，具体包括，所述物联网平台确定所述终端设备在所述目标网络切片中的寻址信息，并根据所述寻址信息向终端设备发送所述业务消息。
  13. 根据权利要求12所述的方法，其特征在于，所述物联网平台接收所述终端设备发送的注册请求，具体包括，
    所述物联网平台接收所述终端设备通过第一网络切片发送的注册请求，所述第一网络切片为不同于所述目标网络切片的网络切片；
    所述物联网平台指示所述终端设备接入所述目标网络切片；
    所述物联网平台接收所述终端设备通过所述目标网络切片发送的注册请求，通过所述目标网络切片发送的注册请求中包括所述终端设备在所述目标网络切片中的寻址信息。
  14. 根据权利要求12所述的方法，其特征在于，所述物联网平台接收所述终端设备发送的注册请求，具体包括，
    所述物联网平台接收所述终端设备通过第一网络切片发送的注册请求，所述第一网络切片为所述目标网络切片中的一个网络切片；
    所述物联网平台指示所述终端设备接入所述目标网络切片，所述目标网络切片中还包括除所述第一网络切片之外的其它网络切片；
    所述物联网平台接收所述终端设备通过所述目标网络切片中任一网络切片发送的注册请 求，通过所述目标网络切片中任一网络切片发送的注册请求中包括所述终端设备在所述目标网络切片中的寻址信息。
  15. 根据权利要求13或14所述的方法，其特征在于，所述物联网平台指示所述终端设备接入所述目标网络切片，具体包括，所述物联网平台向所述终端设备发送所述业务特征以及与所述业务特征对应的所述目标网络切片的信息，所述业务特征以及与所述业务特征对应的所述目标网络切片的信息用于指示所述终端设备接入所述目标网络切片，并通过所述目标网络切片向所述物联网平台注册。
  16. 根据权利要求2所述的方法，其特征在于，所述物联网平台获取所述业务特征以及与所述业务特征对应的所述目标网络切片的信息，具体包括，
    所述物联网平台从所述终端设备获取所述业务特征以及与所述业务特征对应的所述目标网络切片的信息。
  17. 根据权利要求16所述的方法，其特征在于，所述物联网平台从所述终端设备获取所述业务特征以及与所述业务特征对应的所述目标网络切片的信息，具体包括，
    所述物联网平台接收经所述目标网络切片传输的来自所述终端设备的消息；
    所述物联网平台从所述经所述目标网络切片传输的来自所述终端设备的消息中，获得所述业务特征，及所述目标网络切片的信息。
  18. 根据权利要求1-17任一所述的方法，其特征在于，所述物联网平台通过所述目标网络切片，将所述业务消息发送至终端设备之前，所述方法还包括，所述物联网平台建立与所述目标网络切片中网元的连接。
  19. 根据权利要求18所述的方法，其特征在于，所述物联网平台建立与所述目标网络切片中网元的连接，具体包括，所述物联网平台根据所述终端设备的标识从底层网络的网络切片管理功能获取所述目标网络切片中为所述终端设备服务的网元的地址，并根据所述目标网络切片中网元的地址建立与所述目标网络切片中网元的连接。
  20. 根据权利要求1-19任一所述的方法，其特征在于，所述目标网络切片的信息至少包括如下任一信息，目标网络切片标识或名称，目标网络切片类型，目标网络切片所属运营商标识或名称，目标网络切片中网元的地址。
  21. 根据权利要求1-20任一所述的方法，其特征在于，所述业务特征至少包括如下任一特征，源应用标识或类型，目的应用标识或类型，源业务中间件标识或类型，目的业务中间件标识或类型，业务资源标识或类型，业务消息类型，操作方法，消息优先级。
  22. 一种物联网业务路由的方法，其特征在于，
    终端设备接收来自物联网平台的消息，所述消息中包括业务特征以及与所述业务特征对应的目标网络切片的信息；
    所述终端设备通过所述目标网络切片向所述物联网平台注册；
    所述终端设备通过所述目标网络切片向所述物联网平台发送上行业务消息，或通过所述 目标网络切片接收来自所述物联网平台的下行业务消息，所述上行业务消息和所述下行业务消息为符合所述业务特征的业务消息。
  23. 根据权利要求22所述的方法，其特征在于，所述终端设备接收来自物联网平台的消息之前，所述终端设备通过第一网络切片向所述物联网平台注册；所述终端设备接收来自物联网平台的消息，具体包括，所述终端设备通过所述第一网络切片接收所述来自物联网平台的消息。
  24. 根据权利要求22或23所述的方法，其特征在于，所述终端设备通过所述目标网络切片向所述物联网平台注册的注册请求中，包括所述终端设备在所述目标网络切片中的寻址信息。
  25. 一种物联网业务路由的方法，其特征在于，
    终端设备通过目标网络切片向物联网平台注册；
    所述终端设备通过所述目标网络切片向所述物联网平台发送消息，所述消息中包括业务特征以及与所述业务特征对应的目标网络切片的信息；
    所述终端设备通过所述目标网络切片，接收来自所述物联网平台的、符合所述业务特征的业务消息。
  26. 一种用于实现物联网业务路由的装置，其特征在于，包括通信接口，存储器和处理器；其中所述通信接口用于与所述装置外的实体或其它装置进行通信，所述处理器与所述存储器和所述通信接口连接，当所述装置运行时，所述处理器执行所述存储器存储的计算机执行指令，以使所述装置执行如权利要求1-21任一所述方法中物联网平台的功能。
  27. 一种用于实现物联网业务路由的装置，其特征在于，包括通信接口，存储器和处理器；其中所述通信接口用于与所述装置外的实体或其它装置进行通信，所述处理器与所述存储器和所述通信接口连接，当所述装置运行时，所述处理器执行所述存储器存储的计算机执行指令，以使所述装置执行如权利要求22-24任一所述方法中终端设备的功能。
  28. 一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如权利要求1-21任意一项所述的方法。
  29. 一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如权利要求22-24任意一项所述的方法。
PCT/CN2019/091448 2018-06-20 2019-06-16 一种物联网业务路由的方法 WO2019242574A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19823643.2A EP3800934A4 (en) 2018-06-20 2019-06-16 METHOD OF ROUTING INTERNET OF THINGS SERVICE
US17/126,772 US11716669B2 (en) 2018-06-20 2020-12-18 Internet of things service routing method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810637157.3A CN110621045B (zh) 2018-06-20 2018-06-20 一种物联网业务路由的方法
CN201810637157.3 2018-06-20

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/126,772 Continuation US11716669B2 (en) 2018-06-20 2020-12-18 Internet of things service routing method

Publications (1)

Publication Number Publication Date
WO2019242574A1 true WO2019242574A1 (zh) 2019-12-26

Family

ID=68920631

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/091448 WO2019242574A1 (zh) 2018-06-20 2019-06-16 一种物联网业务路由的方法

Country Status (4)

Country Link
US (1) US11716669B2 (zh)
EP (1) EP3800934A4 (zh)
CN (1) CN110621045B (zh)
WO (1) WO2019242574A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113708946A (zh) * 2020-05-20 2021-11-26 平头哥(杭州)半导体有限公司 计算系统及消息路由方法

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112823564A (zh) * 2018-10-04 2021-05-18 瑞典爱立信有限公司 提供动态nef隧道分配的方法和相关的网络节点/功能
US20220311673A1 (en) * 2019-08-30 2022-09-29 Qiang ZU Method for Onboarding a Network Function Package in ONAP
US11638312B2 (en) * 2020-02-13 2023-04-25 Qualcomm Incorporated Slice allocation
CN113301586B (zh) * 2020-02-24 2023-04-18 华为技术有限公司 网络选择方法及电子设备
CN113395612B (zh) * 2020-03-11 2022-11-22 华为技术有限公司 一种光纤通信中的数据转发方法以及相关装置
CN111291035B (zh) * 2020-03-23 2023-05-16 东软睿驰汽车技术（沈阳）有限公司 一种对数据进行切片的方法、装置及相关产品
CN113498084B (zh) * 2020-04-07 2022-07-29 烽火通信科技股份有限公司 一种层次化的基于切片的5g业务承载方法及系统
CN116827790A (zh) * 2020-05-29 2023-09-29 中兴通讯股份有限公司 接入网络切片的方法、电子设备及存储介质
CN113949634A (zh) * 2020-07-16 2022-01-18 华为技术有限公司 一种报文传输的方法、装置及系统
CN114095421B (zh) * 2020-07-30 2023-12-29 深信服科技股份有限公司 一种网络选路方法、装置、设备及计算机可读存储介质
CN114095365B (zh) * 2020-08-24 2023-07-21 中移物联网有限公司 基于5g消息的物联网业务的处理方法及装置
CN114205184B (zh) * 2020-08-28 2023-05-02 大唐移动通信设备有限公司 业务数据传输方法及装置
CN114125888A (zh) * 2020-09-01 2022-03-01 中国移动通信有限公司研究院 标识分配方法、装置、设备及存储介质
CN114258020B (zh) * 2020-09-25 2023-12-12 中移物联网有限公司 专有云部署方法、平台及电子设备
CN115277458B (zh) * 2021-04-30 2023-11-17 阿里巴巴新加坡控股有限公司 服务提供方法、设备及存储介质
US20220417823A1 (en) * 2021-06-29 2022-12-29 At&T Intellectual Property I, L.P. Method and system for network slice-based high priority service handling in radio access technology (rat) switching
CN115695198A (zh) * 2021-07-22 2023-02-03 中兴通讯股份有限公司 感知数据传输方法、电子设备、计算机可读存储介质
CN115733786A (zh) * 2021-08-27 2023-03-03 中兴通讯股份有限公司 路由和云资源注册方法及装置、存储介质和电子装置
CN116074807A (zh) * 2021-11-03 2023-05-05 华为技术有限公司 一种数据收集方法及通信装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106550410A (zh) * 2015-09-17 2017-03-29 华为技术有限公司 一种通信控制方法和控制器、用户设备、功能实例
CN107659419A (zh) * 2016-07-25 2018-02-02 华为技术有限公司 网络切片方法和系统

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103650437B (zh) * 2013-06-28 2016-11-16 华为技术有限公司 任播服务注册、实现方法及装置、交换设备和系统
CN106657194B (zh) 2015-11-02 2020-05-08 中兴通讯股份有限公司 一种网络切片能力开放的方法、装置及系统
CN106937362B (zh) 2015-12-31 2020-04-14 华为技术有限公司 网络切片管理装置和网络切片管理方法
CN107040481A (zh) * 2016-02-04 2017-08-11 中兴通讯股份有限公司 一种网络切片选择方法、策略生成方法及网络节点
US10966128B2 (en) * 2016-02-15 2021-03-30 Telefonaktiebolaget Lm Ericsson (Publ) Network nodes and methods performed therein for enabling communication in a communication network
CN107087255B (zh) * 2016-02-15 2020-01-14 中兴通讯股份有限公司 一种终端位置管理、终端移动性管理的方法及网络节点
CN108702722A (zh) * 2016-02-17 2018-10-23 Lg 电子株式会社 在无线通信系统中发送/接收位置注册有关消息的方法及其装置
CN107295609B (zh) * 2016-03-30 2021-06-15 中兴通讯股份有限公司 网络切片处理方法及装置、终端、基站
CN107277883A (zh) 2016-04-08 2017-10-20 电信科学技术研究院 在多网络切片的网络中路由消息的方法、设备及系统
CN107580360A (zh) 2016-07-04 2018-01-12 中国移动通信有限公司研究院 一种网络切片选择的方法、设备及网络架构
CN107809776B (zh) * 2016-09-09 2021-06-15 中兴通讯股份有限公司 信息处理方法、装置以及网络系统
US11240660B2 (en) * 2016-09-18 2022-02-01 Alcatel Lucent Unified security architecture
CN107872345B (zh) * 2016-09-28 2021-04-06 中兴通讯股份有限公司 一种能力开放实现方法及装置
CN106572516B (zh) * 2016-09-28 2021-02-12 华为技术有限公司 一种网络切片选择方法、终端设备及网络设备
WO2018188767A1 (en) * 2017-04-13 2018-10-18 NEC Laboratories Europe GmbH Joint iot broker and network slice management component
FR3067197A1 (fr) * 2017-06-01 2018-12-07 Orange Procede de selection d'une tranche de reseau relative a une application
US11696213B2 (en) * 2018-03-15 2023-07-04 Nokia Technologies Oy Network slice discovery in overlapping network slice deployment
US10437581B1 (en) * 2018-04-20 2019-10-08 At&T Mobility Ii Llc Internet of things platform for handling firmware transfer on machine-to-machine devices

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106550410A (zh) * 2015-09-17 2017-03-29 华为技术有限公司 一种通信控制方法和控制器、用户设备、功能实例
CN107659419A (zh) * 2016-07-25 2018-02-02 华为技术有限公司 网络切片方法和系统

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HUAWEI: "Network Slice instance selection", SA WG2 MEETING #122, S2-175045, 29 June 2017 (2017-06-29), XP051303743 *
See also references of EP3800934A4

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113708946A (zh) * 2020-05-20 2021-11-26 平头哥(杭州)半导体有限公司 计算系统及消息路由方法
CN113708946B (zh) * 2020-05-20 2024-01-05 平头哥(杭州)半导体有限公司 计算系统及消息路由方法

Also Published As

Publication number Publication date
CN110621045A (zh) 2019-12-27
US20210136653A1 (en) 2021-05-06
CN110621045B (zh) 2022-05-13
EP3800934A1 (en) 2021-04-07
US11716669B2 (en) 2023-08-01
EP3800934A4 (en) 2021-07-28

Similar Documents

Publication Publication Date Title
WO2019242574A1 (zh) 一种物联网业务路由的方法
KR102047382B1 (ko) 사용자 장비를 위한 이동 코어 네트워크 서비스 노출
CN114145054B (zh) 用于支持流量导向通过服务功能链的系统和方法
KR102224248B1 (ko) 통신 시스템에서 PDU(Protocol Data Unit) 세션을 설립하는 방법
WO2020147760A1 (zh) 一种局域网通信方法、装置及系统
KR102116401B1 (ko) M2m 서비스 계층에 대한 교차 리소스 가입
JP6946607B2 (ja) 通信システム、セッション管理機能エンティティ、およびプログラム
US20210168902A1 (en) User Group Session Management Method and Apparatus
KR102419113B1 (ko) 서비스 품질 모니터링 방법 및 시스템, 및 장치
KR102500594B1 (ko) 통신 네트워크에서의 서비스 계층 메시지 템플릿들
WO2019157963A1 (zh) 用于数据传输的方法、移动管理设备、数据业务处理设备和终端
US20230269794A1 (en) Local network accessing method and apparatus
WO2020253343A1 (zh) 一种管理服务的发现方法及装置
WO2019068223A1 (en) GROUP CONFIGURATION AND MANAGEMENT IN DEVICE-TO-DEVICE COMMUNICATIONS
US20220124008A1 (en) Automated Service Layer Message Flow Management In A Communications Network
EP3912329B1 (en) Automated service layer message flow management in a communications network
WO2023041054A1 (zh) 网络验证的方法和装置
WO2021115447A1 (zh) 会话管理网元发现的方法、设备及系统
WO2023213177A1 (zh) 一种通信方法及装置
WO2023056784A1 (zh) 数据收集方法、通信装置及通信系统
WO2022165787A1 (zh) 参数配置方法、装置、设备及存储介质
US20210092202A1 (en) Service layer methods for offloading iot application message generation and response handling

Legal Events

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

Ref document number: 19823643

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019823643

Country of ref document: EP

Effective date: 20201228