CN115529590A

CN115529590A - Capacity opening information acquisition method and device and communication equipment

Info

Publication number: CN115529590A
Application number: CN202110705559.4A
Authority: CN
Inventors: 朱磊; 种璟; 唐小勇; 罗柯; 游正朋
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Chengdu ICT Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Chengdu ICT Co Ltd
Priority date: 2021-06-24
Filing date: 2021-06-24
Publication date: 2022-12-27
Also published as: WO2022267959A1

Abstract

The application discloses a method and a device for acquiring capability opening information and communication equipment. The method comprises the following steps: the first equipment sends a first request to the third equipment; the first request is used for requesting capability opening; the first request comprises identity authentication information used for authentication; the first equipment acquires the capability opening information from the third equipment; the capability opening information is obtained after the identity authentication information is authenticated by the third equipment.

Description

Capacity opening information acquisition method and device and communication equipment

Technical Field

The present application relates to wireless communication technologies, and in particular, to a method, an apparatus, and a communication device for acquiring capability opening information.

Background

The fifth generation mobile communication technology (5G) as a new generation communication technology has many advantages such as large bandwidth, low time delay, high reliability, high connectivity, ubiquitous network, and the like, thereby promoting rapid development and alternation of the vertical industry, such as the rise of the directions of smart medical treatment, smart education, smart agriculture, and the like.

The multi-access edge computing (MEC) technology, one of the key technologies of 5G evolution, is an Information Technology (IT) general platform with wireless network information Application Program Interface (API) interaction capability and computing, storing and analyzing functions; by means of the MEC technology, traditional external application can be pulled into an operator, localized application service is provided for a user, and the method is closer to the user, so that user experience is improved, and more values of an edge network are exerted.

By combining the 5G technology and the MEC technology, different technology combinations such as Quality of Service (QoS), end-to-end network slicing, network capability opening, edge cloud and the like can be introduced to different industry requirement scenes, so that a customized solution is provided.

In the related art, a scheme combining 5G and MEC technology as shown in fig. 1 is adopted, and the scheme has a safety risk. Therefore, in some scenarios, a device (or called gateway) is arranged to implement a service agent with an open network capability between a core network and an MEC platform (MEP) and between a User Plane Function (UPF) and the MEP, thereby ensuring and improving the network security capability of the communication system. However, in such a scenario, how to obtain the network openness capability information, no effective solution is available at present.

Disclosure of Invention

In order to solve the existing technical problem, embodiments of the present application provide a capability openness information obtaining method, a capability openness information obtaining device, and a communication device.

The technical scheme of the embodiment of the application is realized as follows:

in a first aspect, an embodiment of the present application provides a method for acquiring capability openness information, where the method includes:

the first equipment sends a first request to the third equipment; the first request is used for requesting capability opening; the first request comprises identity authentication information used for authentication;

the first equipment acquires the capability opening information from the third equipment; the capability opening information is obtained after the identity authentication information is authenticated by the third equipment.

In the above scheme, the method further comprises:

the first equipment sends a second request to the second equipment, wherein the second request is used for requesting capability information; the capability information is used for indicating the capability which can be obtained by the first equipment;

the first device receives the capability information from the second device.

In the above solution, the capability information includes at least one of the following information: capability identification, type information of the third device, a domain name of the third device, an Internet Protocol (IP) address of the third device, and identity authentication information of the third device.

In the above solution, the capability identifier includes at least one of: location service capability identification, wireless network information service capability identification, monitoring capability identification, pre-configuration capability identification and policy/charging capability identification.

In the foregoing solution, the wireless network information service capability identifier includes at least one of: the system comprises a wireless access network information identifier, a slicing capability identifier, an access user capability identifier, a multi-standard network access identifier and a data statistics report capability identifier.

In the foregoing solution, the type information of the third device includes at least one of: a wireless access network identifier, a network function identifier of a core network, and a third-party system identifier.

In the above scheme, the method further comprises:

under the condition that the first equipment cannot acquire capability opening information from the third equipment, the first equipment sends first information to second equipment, wherein the first information is used for indicating capability acquisition failure;

the first device receives second information from the second device, wherein the second information comprises capability acquisition fault repair information.

In the above scheme, the method further comprises:

the first equipment sends a first access authentication request to the second equipment, wherein the first access authentication request comprises authentication requirement information and capability information supported by the first equipment;

the first equipment receives a first access authentication response from the second equipment, wherein the first access authentication response comprises authentication information of fourth equipment;

the first device transmits a broadcast message based on authentication information of the fourth device; the broadcast message is used for the fourth equipment which receives the broadcast message to initiate access authentication;

the first device receives a second access authentication request from a fourth device;

and the first equipment authenticates the fourth equipment based on the authentication information of the fourth equipment, and sends a second access authentication response to the fourth equipment after the authentication is passed.

In the foregoing solution, the capability information supported by the first device includes at least one of the following information: the device comprises an identifier of the first device, a network type that the first device supports access, an indication of whether the first device supports capability opening, an indication of whether the first device indicates Internet Security Protocol (IPSec), performance information of the first device, and an indication of whether the first device supports wide area interconnection.

In the foregoing solution, the performance information of the first device includes at least one of the following: interface bandwidth of the first device, and a number of fourth devices supported by the first device.

In the foregoing solution, the authentication information of the fourth device includes at least one of the following information: the identity of the fourth device, the IP address of the fourth device, the domain name of the fourth device, and the identity authentication information of the fourth device.

In the foregoing solution, the method further includes: and the first equipment sends the capability information to fourth equipment.

In the above solution, when the capability information includes a slice capability identifier, the capability information further includes configuration information of slice parameter templates, the number of slice parameter templates, and the identifier of the slice parameter template.

In the above scheme, the configuration information of the slice parameter template includes at least one of the following slice parameters and value ranges thereof:

the maximum number of users is supported by the slice;

slicing a service area;

slicing end-to-end delay;

the moving grade of the terminal in the slice;

slice resource sharing level;

slicing reliability requirements.

In the above scheme, the method further comprises:

the first device receiving a first slice configuration request from the fourth device; the first slice configuration request comprises indication information used for indicating the type of the standard slice parameter template and an identifier of the standard slice parameter template, or comprises indication information used for indicating the type of the custom slice parameter template and custom template parameters;

the first device determines a corresponding standard template parameter based on the identifier of the standard slice parameter template, and sends a second slice configuration request to a second device after the standard template parameter or the custom template parameter passes legal check, wherein the second slice configuration request comprises the standard template parameter or the custom template parameter, and the standard template parameter or the custom template parameter is used for the second device to complete the configuration of a network slice;

the first device receives a second slice configuration response from the second device, wherein the second slice configuration response comprises a network slice instance identifier;

the first device sends a first slice configuration response to the fourth device, wherein the first slice configuration response comprises the network slice instance identifier.

In a second aspect, an embodiment of the present application further provides a capability openness information obtaining method, where the method includes:

the third device receives the first request from the first device; the first request is used for requesting capability opening; the first request comprises identity authentication information used for authentication;

and the third equipment authenticates the first equipment based on the identity authentication information, and sends capability opening information to the first equipment after the authentication is passed.

In the foregoing solution, the sending capability openness information to the first device includes:

and the third equipment opens a capability application programming interface and sends capability opening information to the first equipment based on the opened capability application programming interface.

In the above scheme, the method further comprises:

transmitting a message between the third device and the first device;

terminating opening the capability application programming interface to the first device if the third device does not receive a message from the first device.

In the above scheme, the method further comprises:

the third equipment authenticates the first equipment through second equipment;

and the third equipment sends capability information to the second equipment, wherein the capability information is used for indicating the capability which can be obtained by the first equipment, and the capability information is sent after the first equipment is authenticated.

In the above scheme, the capability information includes at least one of the following information: the capability identification, the type information of the third device, the domain name of the third device, the IP address of the third device, and the identity authentication information of the third device.

In a third aspect, an embodiment of the present application further provides a capability openness information obtaining method, where the method includes:

the second device receives a second request from the first device, wherein the second request is used for requesting the capability information;

and the second equipment sends the capability information to the first equipment, wherein the capability information is used for indicating the capability which can be obtained by the first equipment.

In the above solution, the capability information includes at least one of the following information: the capability identifier, the type information of the third device, the domain name of the third device, the Internet Protocol (IP) address of the third device, and the identity authentication information of the third device.

In the above solution, the wireless network information service capability identifier includes at least one of: the system comprises a wireless access network information identifier, a slicing capability identifier, an access user capability identifier, a multi-standard network access identifier and a data statistics report capability identifier.

In the above scheme, the method further comprises:

the second equipment receives a first access authentication request from the first equipment, wherein the first access authentication request comprises authentication requirement information and capability information supported by the first equipment;

after the second device passes the authentication of the first device, sending a first access authentication response to the first device, wherein the first access authentication response comprises authentication information of a fourth device; and the authentication information of the fourth equipment is used for the fourth equipment to access the first equipment.

In the foregoing solution, the capability information list supported by the first device includes at least one of the following information: the identifier of the first device, the type of the network that the first device supports accessing, an indication of whether the first device supports network capability opening, an indication of whether the first device indicates IPSec, performance information of the first device, and an indication of whether the first device supports wide area interconnection.

In the foregoing solution, the performance information of the first device includes at least one of: interface bandwidth of the first device, and a number of fourth devices supported by the first device.

In a fourth aspect, an embodiment of the present application further provides a method for acquiring capability openness information, where the method includes:

the fourth device receives capability information from the first device, wherein the capability information is used for indicating the capability which can be obtained by the first device;

and the fourth equipment processes the corresponding capacity based on the capacity information.

In the foregoing solution, the receiving, by the fourth device, the capability information from the first device includes:

the agent function component of the fourth device performs information interaction with the first device and receives capability information from the first device;

correspondingly, the fourth device performs corresponding processing based on the capability information, including:

and the application component of the fourth equipment performs corresponding processing based on the capability information.

In the above solution, the capability information includes at least one of the following information: the capability identification, the type information of the third device, the domain name of the third device, the IP address of the third device, and the identity authentication information of the third device.

In the above solution, the capability identifier includes at least one of: a location service capability identifier, a wireless network information service capability identifier, a monitoring capability identifier, a pre-configuration capability identifier and a strategy/charging capability identifier;

wherein the wireless network information service capability identification comprises at least one of: the system comprises a wireless access network information identifier, a slicing capability identifier, an access user capability identifier, a multi-mode network access identifier and a data statistics report capability identifier.

In the foregoing solution, when the wireless network information service capability identifier includes an access user capability identifier, the fourth device performs processing of a corresponding capability based on the capability information, including:

and the fourth equipment manages the accessed user based on the access user capacity identification.

In the above scheme, the method further comprises:

the fourth device sends at least one of the following information to the first device: the mobile phone number of the access user, the user name of the access user, the IP address of the access user and the access application identification.

In the above scheme, when the wireless network information service capability identifier includes a slicing capability identifier, the capability information further includes configuration information of slicing parameter templates, the number of slicing parameter templates, and identifiers of slicing parameter templates;

the configuration information of the slice parameter template comprises at least one of the following slice parameters and the value ranges thereof:

the maximum number of users is supported by the slice;

slicing a service area;

slicing end-to-end delay;

the moving grade of the terminal in the slice;

slice resource sharing level;

slice reliability requirements.

In the foregoing solution, the processing of the corresponding capability by the fourth device based on the capability information includes:

the fourth device sends a first slice configuration request to the first device, wherein the first slice configuration request comprises indication information used for indicating a standard slice parameter template type or indication information used for indicating a custom slice parameter template type and a custom template parameter;

the fourth device receives a first slice configuration response from the first device, wherein the first slice configuration response comprises the network slice instance identification.

In the foregoing solution, the method further includes:

the fourth device receives a broadcast message from the first device;

based on the broadcast message, the fourth device sends a second access authentication request to the first device; the second access authentication request is used for the first device to perform access authentication on the fourth device;

receiving a second access authentication response from the first device.

In a fifth aspect, an embodiment of the present application further provides a capability openness information obtaining apparatus, where the apparatus includes: a first transmitting unit and a first receiving unit; wherein the content of the first and second substances,

the first sending unit is used for sending a first request to a third device; the first request is used for requesting capability opening; the first request comprises identity authentication information used for authentication;

the first receiving unit is configured to acquire capability opening information from the third device; the capability opening information is obtained after the identity authentication information is authenticated by the third equipment.

In a sixth aspect, an embodiment of the present application further provides a capability openness information obtaining apparatus, where the apparatus includes: the second receiving unit, the second processing unit and the second sending unit; wherein the content of the first and second substances,

the second receiving unit is used for receiving a first request from the first device; the first request is used for requesting capability opening; the first request comprises identity authentication information used for authentication;

the second processing unit is configured to authenticate the first device based on the identity authentication information;

and the second sending unit is used for sending the capability opening information to the first equipment after the authentication of the second processing unit is passed.

In a seventh aspect, an embodiment of the present application further provides a capability openness information obtaining apparatus, where the apparatus includes: a third receiving unit and a third transmitting unit; wherein the content of the first and second substances,

the third receiving unit is configured to receive a second request from the first device, where the second request is used to request capability information;

the third sending unit is configured to send the capability information to the first device, where the capability information is used to indicate a capability that the first device can obtain.

In an eighth aspect, an embodiment of the present application further provides a capability openness information obtaining apparatus, where the apparatus includes: a fourth receiving unit and a fourth processing unit; wherein the content of the first and second substances,

the fourth receiving unit is configured to receive capability information from a first device, where the capability information is used to indicate a capability that the first device can obtain;

and the fourth processing unit is used for processing the corresponding capacity based on the capacity information.

In a ninth aspect, embodiments of the present application further provide a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps of the method according to the first, second, third or fourth aspect of the embodiments of the present application.

In a tenth aspect, an embodiment of the present application further provides a communication device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, where the processor executes the program to implement the steps of the method in the first, second, third, or fourth aspects of the embodiment of the present application.

According to the method, the device and the communication equipment for acquiring the capability opening information, the first request is sent to the third equipment through the first equipment; the first request is used for requesting capability opening; the first request comprises identity authentication information used for authentication; the first equipment acquires the capability opening information from the third equipment; the capability opening information is obtained after the identity authentication information is authenticated by the third equipment. By adopting the technical scheme of the embodiment of the application, the industry gateway (namely the first equipment) can acquire the capability opening information from the third equipment (namely the capability source, such as RAN, 5GC and a third-party network).

Drawings

FIG. 1 is a schematic diagram of a related art system structure combining 5G and MEC technologies;

fig. 2 is a schematic structural diagram of a system for 5G industry cloud network convergence according to an embodiment of the present application;

fig. 3 is a first flowchart illustrating a capability openness information obtaining method according to an embodiment of the present application;

fig. 4 is a flowchart illustrating a second method for acquiring capability openness information according to an embodiment of the present application;

fig. 5 is a third schematic flow chart of a capability openness information acquisition method according to an embodiment of the present application;

fig. 6 is a fourth flowchart illustrating a capability openness information obtaining method according to an embodiment of the present application;

fig. 7 is a schematic diagram of a network capability open architecture of cloud network convergence in the industry 5G of the application embodiment of the present application;

fig. 8 is a schematic diagram of an MEP capability open function architecture according to an embodiment of the present application;

fig. 9 is an interaction flow diagram of a capability openness information acquisition method according to an embodiment of the present application;

fig. 10 is a schematic view illustrating an access authentication interaction flow in a capability openness information acquisition method according to an embodiment of the present application;

fig. 11 is a schematic view illustrating a slice configuration flow in a capability openness information acquisition method according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of a first configuration of a capability openness information acquiring apparatus according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of a second configuration of the capability openness information acquiring apparatus according to the embodiment of the present application;

fig. 14 is a schematic structural diagram of a third component of the capability openness information acquiring apparatus according to the embodiment of the present application;

fig. 15 is a schematic structural diagram of a component of a capability openness information acquiring apparatus according to an embodiment of the present application;

fig. 16 is a schematic diagram of a hardware component structure of a communication device according to an embodiment of the present application.

Detailed Description

The present application will be described in further detail with reference to the following drawings and specific embodiments.

As shown in fig. 1, in the related art, the scheme of combining 5G with MEC mainly includes:

1) In order to enable low-delay, high-bandwidth and high-reliability edge application of the vertical industry, a UPF sinks to an industry client park, is close to an MEC edge server (also called an MEC platform (MEP)), and forwards data to the MEP through a local distribution technology of the UPF (namely an Uplink filter/IPv 6 branch Point (UL-CL/IPv 6 BP, uplink Classifier/IPv6 Branching Point));

2) An Application Function (AF) in the core network is sunk to the MEP side, and provides better data flow control policies (such as coding policies, qoS policies, routing policies, etc.) for applications deployed on the MEP.

However, the scheme of fig. 1, in which 5G is combined with MEC technology, presents the following safety risks:

first, the deployment location of the UPF and MEP poses a security risk.

Specifically, the UPF and MEP are functionally logically separate, but may be deployed in two ways, respectively: merging deployment and separating deployment; the merged deployment refers to that the UPF and the MEP are deployed in the same machine room or even on the same physical equipment; separate deployment refers to the deployment of UPFs and MEPs in different rooms. In practical applications, the merged deployment is not suitable for vertical industries (such as intelligent medical, intelligent education, intelligent agriculture, etc.), because: if the UPF and the MEP are merged and deployed in an operator machine room, the safety requirement that an industrial customer cannot export the application data of the industrial customer from the park is violated; and if the UPF and the MEP are merged and deployed in an industrial customer park machine room, the operation and maintenance of an operator are very unfavorable, and the security risk of the whole core network can be improved. Therefore, for vertical industry applications, the UPF and the MEP should be deployed separately, specifically, the UPF may be deployed in an operator room, and the MEP may be deployed in an industry customer park room. However, in a scenario where the UPF and the MEP are separately deployed, data security between the UPF and the MEP cannot be guaranteed, and a security risk exists.

Second, security risks caused by ubiquitous network access.

Specifically, the architecture shown in fig. 1 does not relate to access and data transmission of a non-5G network, in other words, the related art does not provide an access scheme of a non-5G network when 5G is combined with MEC technology. The access technologies of terminals in the vertical industry are various in types, and include, in addition to 5G, a fourth-generation mobile communication technology (4G), wireless fidelity (Wi-Fi), bluetooth (Bluetooth), zigbee (Zigbee), narrowband Internet of Things (NB-IoT, narrow Band-Internet of Things), a wired network (wired), and the like, and terminal data accessed by these non-5G networks may not be transmitted to the MEP through the 5G network, so that the MEP cannot perform access control, traffic control, and security monitoring on the terminal data of various access technologies, cannot ensure network and data security of the MEP, and has a security risk.

Third, network capabilities open up resulting security risks.

Specifically, as shown in fig. 1, in the related art, the Network Capability openness Function (SCEF) of the MEP is implemented by interfacing the AF on the MEP with the Network openness Function (NEF) of the 5G Core Network (5 gc,5G Core). However, since the security level on each MEP is not uniform, when the MEP opens the network capability outwards, the core network may be attacked and there is a security risk because a security hole exists in the network capability application on a certain MEP or a security mechanism problem of a certain MEP itself exists.

In addition, in the related art, the MEP can only obtain the network capability from the 5GC, and the network capability provided by the 5GC cannot completely meet and accurately cover the service requirement of the vertical industry, such as the location information of the terminal which cannot provide the non-5G network access. Meanwhile, the MEP Network capability has various data sources including 5GC, radio Access Network (RAN), third party system and the like, but a scheme for uniform authentication, uniform supervision and uniform settlement of the Network capability is lacked in the related technology.

Fourth, security risks due to local breakout.

Specifically, as shown in fig. 1, in the related art, data forwarding from a terminal to a local MEP depends on the UL-CL/IPv6 BP technology of UPF, which implements local breakout based on an IP five-tuple or a prefix of a packet. In practical application, for a vertical industry, the UL-CL/IPv6 BP technology is used for local distribution, and the IP address information of the MEP of an industrial user is exposed on a public network, so that not only is the risk of leakage of user privacy data, but also network attack on the IP address of the MEP is possibly caused, and the network security risk exists.

In practical application, in order to avoid a Network security risk caused by local distribution using the UL-CL/IPv6 BP technology, it is also considered that local distribution is implemented by setting a dedicated Data Network Name (DNN) for the MEP. However, this approach requires a separate DNN for each MEP, and requires a large number of DNN configurations in the core network. Moreover, for a scenario that one terminal accesses a plurality of MEPs, a user needs to continuously switch DNNs on the terminal, which seriously affects user experience.

In addition, in practical application, in a vertical industry application scenario, besides a local distribution requirement, a requirement of wide area interconnection between MEPs also exists, such as data sharing, remote collaborative diagnosis and the like between different hospitals. However, in the related art, the UPF supports only a Protocol Data Unit (PDU) session of a terminal to a Data Network (DN), and does not support a DN to DN connection. In other words, the UPF supports only data connection of terminals to MEPs, and does not support interconnection between MEPs.

Based on this, in various embodiments of the present application, as shown in fig. 2, an industry gateway (may also be referred to as a gateway) is provided, and through the industry gateway, a service proxy for opening network capabilities between a core network and an MEP and between a UPF and an MEP is implemented; therefore, data safety of the communication system can be guaranteed, network safety capability of the communication system is improved, and user experience is improved.

In an exemplary practical application, the industry gateway is arranged between the UPF and the MEP; an MEP may be a device in an MEC network.

Based at least on the system structure schematic shown in fig. 2, the following embodiments of the present application are proposed.

The embodiment of the application provides a capability openness information acquisition method. Fig. 3 is a first flowchart illustrating a capability openness information obtaining method according to an embodiment of the present application; as shown in fig. 3, the method includes:

step 101: the first equipment sends a first request to the third equipment; the first request is used for requesting capability opening; the first request comprises identity authentication information used for authentication;

step 102: the first equipment acquires the capability opening information from the third equipment; the capability opening information is obtained after the identity authentication information is authenticated by the third equipment.

The capability openness information acquiring method of the embodiment is applied to the first device. Illustratively, the first device is an industry gateway shown in fig. 2, which may also be referred to as a gateway, a gateway device, and the like, and may be denoted as iGW in english. The third device is a network capability source, which is a generic name of a related network and system that can open capability information (or capability data, network capability information or data) to the first device. Illustratively, the third device may be at least one of a RAN, a core network (e.g., 5 GC), or a third party network (e.g., zigbee/Wifi/bluetooth/NB-IoT/wired network, etc.) as shown in fig. 2. The names of the first device and the third device are not limited in the embodiment of the present application as long as the respective functions of the first device and the third device can be realized.

In this embodiment, the first device sends a first request to the third device, where the first request is used to request the capability to be opened, that is, to request the third device to open the capability. The first request comprises identity authentication information used for authentication and is used for being sent to third equipment for local authentication. After the third device passes the authentication based on the identity authentication information, the third device may send capability openness information to the first device through an open capability API Interface (also referred to as a network capability API) by using an open capability Application Programming Interface (API), that is, the first device may obtain the capability openness information from the third device through the open capability API Interface.

The capabilities described in the embodiments of the present application may also be referred to as network capabilities, and for example, the capabilities include at least one of: location service capability, wireless network information service capability, monitoring capability, provisioning capability, policy/charging capability. Accordingly, the capability opening information may be capability information (or capability data) that the related third device is opened corresponding to each capability.

In this embodiment, the first request includes identity authentication information used for authentication, where the identity authentication information is identity authentication information of the third device, and is identity authentication information used for the third device to authenticate the first device when the first device accesses the third device. Illustratively, the authentication information may include an account name and a password.

Optionally, the first request may further include an identifier for indicating that the capability is requested to be opened, where the identifier for indicating that the capability is requested to be opened is used for the first device to request the third device to open the capability API to the first device. Illustratively, the indication of the request openness capability may be implemented by at least a boolean variable, a string, a numeric parameter, or a bitmap (bitmap). When the identifier for indicating that the openness capability is requested is implemented in a boolean variable manner, for example, "False" represents that the openness capability is not requested, and "True" represents that the openness capability is requested. When the identifier indicating the request for the openness capability is implemented in a character string, for example, "No" represents that the openness capability is not requested, and "Yes" represents that the openness capability is requested. When the identifier for indicating the request for the opening capability is implemented in a numerical parameter manner, for example, 0 is used to represent that no opening capability is requested, and the remaining numbers represent that opening capability is requested. When the identifier for indicating the request open capability is realized in a bitmap manner: and using a bit to identify whether the first equipment requests the third equipment to open the capacity to the first equipment, wherein if the bit is set to 1, the request for the open capacity is represented, and if the bit is set to 0, the no request for the open capacity is represented.

In some optional embodiments of the present application, the method further comprises: the first equipment sends a second request to the second equipment, wherein the second request is used for requesting capability information; the capability information is used for indicating the capability which can be obtained by the first equipment; the first device receives the capability information from the second device.

In this embodiment, the second device may be a management System or an Operation System, such as a service Support System (BSS)/Operation Support System (OSS). The name of the second device is not limited in the embodiment of the present application, as long as the function of the second device can be realized.

In this embodiment, the method of this embodiment may be executed before step 101, that is, the first device may first send the second request to the second device to request to obtain which capabilities the first device can obtain and to request related information of a third device that the first device can access, and then send the first request to the related third device according to the obtained capability information to request the related third device to open capability information, so that the first device can obtain capability opening information from the third device.

Optionally, the capability information includes at least one of the following information: the capability identification, the type information of the third device, the domain name of the third device, the IP address of the third device, and the identity authentication information of the third device.

Illustratively, the capability identification includes at least one of: location service capability identification, wireless network information service capability identification, monitoring capability identification, pre-configuration capability identification and policy/charging capability identification.

Illustratively, the wireless network information service capability identification includes at least one of: the system comprises a wireless access network information identifier, a slicing capability identifier, an access user capability identifier, a multi-standard network access identifier and a data statistics report capability identifier.

Illustratively, the type information of the third device includes at least one of: a wireless access network identification, a network function identification of a core network, and a third-party system identification.

In this embodiment, the first device may obtain the capability information through information or control signaling, and the capability information may also be network capability information. Illustratively, the capability information is a set of information, which may also be referred to as a capability information list or a network capability information list.

For example, the content included in the capability information may be as shown in table 1, and includes capability identifiers corresponding to various capabilities obtained by the first device, a type (network capability source such as 5GC, RAN, or third party network) of a third device (i.e., network capability source) corresponding to each capability identifier, and authentication information of the third device corresponding to each capability identifier, where the authentication information is used for performing local authentication on the third device.

TABLE 1

In this embodiment, the capability information may be implemented in a manner of a capability information set or a capability information list. Illustratively, the capability information may include a capability list and an information list of the third device. The capability list may include at least one capability identifier for indicating which type of capability the first device can obtain from the third device.

Illustratively, the capability identification may be implemented by: bitmap, string, numeric parameters, etc. Wherein:

the bitmap implementation mode is as follows: each capability identity may be represented by a bit in the bitmap. For example, the bitmap uses N bits (bits) to store field information, for example, the 0 th bit to the 4 th bit in table 2 may sequentially represent a Radio Network Information Service (RNIS) capability identifier, a Location Based Service (LBS) capability identifier, a monitoring capability identifier, a pre-configuration capability identifier, and a policy/charging capability identifier; other Bit bits are reserved for identification of other network capability types. When the capability of opening a certain type needs to be supported, the corresponding bit is set to be 1, and the bit is set to be 0 when the capability of opening is not supported. For example, when the first device supports opening the location service capability and the Radio Network Information Service (RNIS) capability to the third device, the first bit and the second bit from the right side of table 2 are set to 1, and the remaining bits are set to 0.

TABLE 2

0

……

0

1

The character string implementation mode is as follows: each capability identifier may be represented by a character string, for example, "ce-RNIS" may be used to represent a wireless network information service capability identifier, and "ce-LBS" may be used to represent a location service capability identifier. Of course, in the embodiment of the present application, the character string is not limited to be used to represent the corresponding capability identifier, and an arbitrarily set character string may be used to represent the corresponding capability identifier.

Numerical parameter implementation: each capability identity may be represented by a number. For example: 01 represents a Radio Network Information Service (RNIS) capability identifier, 02 represents a location service capability identifier, 03 represents a monitoring capability identifier, 04 represents a provisioning capability identifier, 05 represents a policy/charging capability identifier, and so on. Of course, in the embodiment of the present application, the above numbers are not limited to represent the corresponding capability identifiers, and any set numbers may be used to represent the corresponding capability identifiers.

In this embodiment, the information list of the third device is used to indicate related information of the third device. The information list of the third device may include at least one of type information of the third device, a domain name of the third device, an IP address of the third device, and identity authentication information of the third device.

Illustratively, the type information of the third device may be represented by a type identifier of the third device. Illustratively, the type identification of the third device may be implemented at least by means of a character string or a numerical parameter. When the type of the third device is represented by a character string, each type is represented by a character string, for example, the type of the third device represented by "source-Zigbee" is Zigbee, and the type of the third device represented by "source-BLE" is bluetooth. When the type of the third device is expressed by a numerical parameter, each type may be expressed by a number, where "07" represents that the type of the third device is bluetooth, and "01" represents that the type of the third device is Zigbee.

Illustratively, the domain name of the third device may be represented by a domain name identification of the third device. Illustratively, the domain name identification of the third device can be realized at least by means of character strings, for example, the domain name address of a third device is represented by "www.cmii-imep1. Cn".

Illustratively, the IP address of the third device may be represented by an IP address identification of the third device. Illustratively, the identification of the IP address of the third device can be realized at least by means of a character string, for example, the IP address of a third device is represented by "117.136.0.22".

For example, the identity authentication information of each third device may include an account name and a password, which are used for the third device to locally authenticate the first device when the first device accesses the third device. Illustratively, the identity authentication information of the third device may be implemented by means of at least a character string or a numerical parameter. When the identity authentication information of the third device is implemented by means of a character string, for example, "hxfe-iGW" represents an account name that the first device accesses to the third device, and "asjdkajsew" represents a password that the first device accesses to the third device. When the identity authentication information of the third device is implemented by means of the numerical parameter, for example, "123563" represents an account name that the first device accesses to one third device, and "123141233" represents a password that the first device accesses to the third device.

In this embodiment, the first device may send the first request to the third device based on information about a domain name and/or an IP address of the third device in the capability information by obtaining the capability information from the second device, and may also obtain the identity authentication information of the third device from the capability information, so that the first request carries the identity authentication information.

In some optional embodiments, the method further comprises: under the condition that the first device cannot acquire the capability opening information from the third device, the first device sends first information to a second device, wherein the first information is used for indicating a capability acquisition fault; the first device receives second information from the second device, wherein the second information comprises capability acquisition fault repair information.

In this embodiment, for example, after the first device sends the first request and the third device opens the capability API, the third device determines to continue to open the capability API or terminate the capability API by transmitting a message between the first device and the third device. Wherein the transmitted message may also be referred to as a heartbeat message. Under the condition that the third device determines to terminate the open capability API, the first device cannot receive capability open information from the third device, and likewise cannot receive a message transmitted by the first device; if the first device can determine that the communication link between the first device and the third device is abnormal, the first device sends first information to the second device, wherein the first information is used for indicating the capacity acquisition fault; the first device receives second information from the second device, wherein the second information comprises capability acquisition fault repair information.

In one embodiment, the first device continuously sends a message to the third device, and if the third device receives the message sent by the first device and determines that the communication link with the first device is normal, the third device may continue to open the capability API; correspondingly, if the third device does not receive the message sent by the first device, it may be determined that the communication link with the first device is abnormal, and it may be determined that the open capability API is terminated. In another embodiment, the third device may send a message to the first device, and after receiving the message sent by the first device, the third device returns a message to the third device; if the third device receives a message returned by the third device within a preset time range, the communication link with the first device can be determined to be normal, and the capability API can be continuously opened; correspondingly, if the third device does not receive the message returned by the third device within the preset time range, and it is determined that the communication link with the first device is abnormal, it may be determined that the open capability API is terminated.

In some optional embodiments of the present application, the method further comprises: the first equipment sends a first access authentication request to the second equipment, wherein the first access authentication request comprises authentication requirement information and capability information supported by the first equipment; the first equipment receives a first access authentication response from the second equipment, wherein the first access authentication response comprises authentication information of fourth equipment; the first device transmits a broadcast message based on authentication information of the fourth device; the broadcast message is used for receiving a fourth device of the broadcast message to initiate access authentication; the first device receives a second access authentication request from a fourth device; and the first equipment authenticates the fourth equipment based on the authentication information of the fourth equipment, and sends a second access authentication response to the fourth equipment after the authentication is passed.

In this embodiment, before the first device requests the third device for capability opening, a multi-level access authentication process needs to be performed among the first device, the second device, and the fourth device. Here, the first device first initiates access authentication to the second device to determine whether the first device has the authority to access the system; after determining that the first device has the authority to access the system, it may be determined that the first device has completed accessing the system, and the first device obtains a first access authentication response from the second device, where the first access authentication response includes authentication information of the fourth device, so that, after the fourth device initiates a second access authentication request to the first device, the first device may perform local authentication on the fourth device initiating the access request based on the authentication information of the fourth device included in the authentication response, and after the authentication is passed, it may be determined that the fourth device completes accessing the first device.

In the embodiments of the present application, the fourth device may be an MEP shown in fig. 2, and may also be referred to as an MEC platform, an MEC server, or the like. The name of the fourth device is not limited in the embodiment of the present application, as long as the function of the fourth device can be realized.

In this embodiment, the access authentication request (e.g., including the first access authentication request and the second access authentication request) may also be referred to as a request, an access request, an authentication request, and so on; accordingly, the above-mentioned access authentication response (e.g., including the first access authentication response and the second access authentication response) may also be referred to as a response, an access response, an authentication response, and so on. In this embodiment, the names of the access authentication request and the access authentication response are not limited.

In this embodiment, the first device may send the first access authentication request to the second device through a message, information, or signaling, so as to report the authentication requirement information and the capability information supported by the first device through the first access authentication request.

Optionally, the authentication requirement information may also be referred to as access authentication requirement information. For example, the authentication requirement information may be represented by an authentication requirement identifier and an access authentication request identifier, that is, the first access authentication request includes the authentication requirement identifier or the access authentication request identifier, which indicates that the message, the information, or the signaling is for requesting access authentication, that is, indicates that the first device requests the second device to verify or authenticate the identity of the first device, so as to complete access to the second device.

Illustratively, the implementation manner of the authentication requirement identifier or the access authentication request identifier at least includes the following: boolean variables, strings, numeric parameters, or bitmap (bitmap); wherein: the description of each implementation can be found in table 3 below. It should be noted that, in the embodiment of the present application, the boolean variable, the character string, and the numerical parameter listed in table 3 are not limited to indicate whether to request to access the second device, and the boolean variable, the character string, and the numerical parameter set arbitrarily may be used to indicate whether to request to access the second device; in this embodiment of the application, it is also not limited that the value of the specific bit of the bitmap is as shown in table 3to indicate whether to request to access the second device, or vice versa, where the bit value is 0 to indicate that access is requested, and the bit value is 1 to indicate that access is not requested.

TABLE 3

Optionally, the capability information supported by the first device includes at least one of the following information: the identifier of the first device, the type of the network that the first device supports accessing, an indication of whether the first device supports capability opening, an indication of whether the first device indicates IPSec, performance information of the first device, and an indication of whether the first device supports wide area interconnection.

Optionally, the performance information of the first device includes at least one of: interface bandwidth of the first device, and a number of fourth devices supported by the first device.

For example, the capability information supported by the first device may be shown in table 4, and may include, for example, an identity of the first device, a network type (e.g., 5G, 4G, WIFI, BLE, etc.) that the first device supports access, performance information of the first device, whether the first device supports capability opening, whether the first device supports IPSec, whether the first device supports wide area interconnection, and the like.

TABLE 4

In this embodiment, the identity of the first device is used to indicate the identity information of the first device to the second device, and each first device accessing the second device has a unique identity. Illustratively, the identity of the first device has at least the following implementation: character strings, numeric parameters. When the identification is implemented by a character string, for example, a character string such as "schx-iGW", "hnzdy-iGW", or "bjzyy-iGW" may be used to represent a different first device. When the identification is implemented by numerical parameters, for example, "001", "002", and "006" may be used to indicate different first devices. In the embodiment of the present application, the character string and the numerical parameter listed above are not limited to represent the identifier of the first device, and the character string and the numerical parameter set arbitrarily may be used to represent the identifier of the first device.

In this embodiment, the capability information supported by the first device is used to report basic capability information of the first device to the second device. Wherein:

the network type that the first device supports access may be represented by a network type identifier that the first device supports access. Illustratively, the network type identification that the first device supports access may be implemented at least by means of a character string, a numerical parameter or a bitmap. When the network types that the first device supports access are expressed by character strings, each network type is expressed by a character string, and for example, "WiFi", "Wireline", "NB-IoT", "Bluetooth", etc., respectively, represents a corresponding network type. When the network types that the first device supports access are represented by numerical parameters, each network type may be represented by a number, for example: 01 for WiFi,02 for NB-IoT,03 for Bluetooth, etc. When the bitmap represents the network type that the first device supports access: each bit is used for identifying a network type, for example, a bitmap uses N bits to store field information, bit0 identifies WiFi, bit1 identifies NB-IoT, bit2 identifies Bluetooth, and the like, when which network types are supported by the first device, the corresponding bit is set to 1, and correspondingly, when which network types are not supported by the first device, the corresponding bit is set to 0.

The interface bandwidth of the first device may be represented by an interface bandwidth identification. Illustratively, the interface bandwidth identifier may be implemented by means of a character string, and is used to indicate a maximum interface bandwidth supported by the first device. For example, the interface bandwidth of the first device is identified as "xx-bw:50Gbps" to be 50Gbps.

The fourth device number supported by the first device may be represented by a supported fourth device number identifier, where the supported fourth device number identifier is used to indicate a maximum number of fourth devices that the first device supports access. Illustratively, the supported fourth device number identification may be implemented by means of a character string or a numerical parameter. When the supported fourth device number identifier is expressed in a character string manner, for example, the identifier is expressed in "MEPs-num:20 "identifies the access of a maximum of 20 fourth devices that can be supported by the first device. When the number of supported fourth devices is indicated by a numerical parameter, for example, the number "20" indicates the access of at most 20 fourth devices that can be supported by the first device.

Whether the first device supports capability opening may be represented by an identifier indicating whether the first device supports capability opening for the fourth device. Illustratively, the identification of whether capability openness is supported has at least the following implementation: boolean variables, strings, numeric parameters, or bitmaps. When the indication of whether to support capability opening is expressed by a boolean variable, for example, "False" represents that capability opening is not supported, and "True" represents that capability opening is supported. When the identifier of whether to support capability opening is represented by a character string, for example, "No" represents that the capability is not supported, and "Yes" represents that the capability is supported. When the identifier of whether or not the capability opening is supported is represented by a numerical parameter, for example, 0 represents that the capability opening is not supported, and the remaining numbers represent that the capability opening is supported. When the flag indicating whether the capability is supported is represented by a bit map, whether the capability is supported is identified by using a bit, for example, the bit is set to 1 to indicate that the capability is supported is open, and the bit is set to 0 to indicate that the capability is not supported is open.

Whether the first device supports IPSec may be indicated by whether the first device supports IPSec, indicating whether the first device supports IPSec. Illustratively, the IPSec identification is supported or not supported at least in the following implementation: boolean variables, strings, numeric parameters, or bitmaps. When the boolean variable indicates whether the IPSec is supported, for example, "False" indicates that IPSec is not supported, and "True" indicates that IPSec is supported. When the identification of whether to support IPSec is expressed by a character string, for example, "No" represents that IPSec is not supported, and "Yes" represents that IPSec is supported. When the numeric parameter indicates whether the IPSec identification is supported, for example, 0 indicates that IPSec is not supported, and the remaining numbers indicate that IPSec is supported. When the bit map indicates whether the IPSec is supported, a bit may be used to indicate whether the IPSec is supported, for example, setting the bit to 1 indicates that the IPSec is supported, and setting the bit to 0 indicates that the IPSec is not supported.

Whether the first device supports wide area interconnection may be represented by whether the first device supports wide area interconnection identification, for indicating whether the first device supports wide area interconnection. The wide area interconnection refers to interconnection between different Data networks (DN, data networks), and in this embodiment, may refer to whether interconnection between a plurality of fourth devices may be implemented through the first device. Illustratively, the indication whether the wide area interconnection is supported has at least the following implementation modes: boolean variables, strings, numeric parameters, or bitmaps. When the wide area interconnection identification is indicated by a boolean variable, for example, "False" indicates that the wide area interconnection is not supported, and "True" indicates that the wide area interconnection is supported. When the wide area interconnection is supported or not is represented by a character string, for example, "No" represents that the wide area interconnection is not supported, and "Yes" represents that the wide area interconnection is supported. When the numerical parameter indicates whether the wan interconnection id is supported, for example, 0 indicates that wan interconnection is not supported, and the rest of the numbers indicate that wan interconnection is supported. When the indication of whether the wide area interconnection is supported or not is represented by a bit, whether the wide area interconnection is supported or not is identified by using a bit, for example, the bit is set to 1 to indicate that the wide area interconnection is supported, and the bit is set to 0 to indicate that the wide area interconnection is not supported.

In this embodiment, the second device authenticates the first device, and sends a first access authentication response to the second device after determining that the first device has the authority to access the system; the first access authentication response comprises authentication information of each fourth device capable of accessing the first device, and the authentication information of the fourth device is used for the first device to perform local authentication on the fourth device requesting access. For example, the authentication information of the fourth device is used to indicate which fourth devices can access the first device, and the authentication information of the fourth device includes an address and identity authentication information of the fourth devices that can access the first device, and is used to support access authentication of the first device to the accessed fourth device.

Optionally, after the authentication (or authentication) of the first device is passed, the second device may obtain capability information that can be obtained by the first device from a third device, and further, after receiving the second request of the first device, the second device sends the capability information to the first device.

Optionally, the authentication information of the fourth device includes at least one of the following information: the identity of the fourth device, the IP address of the fourth device, the domain name of the fourth device, and the identity authentication information of the fourth device. For example, the identity authentication information of the fourth device may include information about an account number and a password of the fourth device.

For example, the authentication information of the fourth device may refer to the table 5, and may include, for example, an identity of the fourth device, an IP address of the fourth device, a domain name of the fourth device, and the authentication information of the fourth device.

TABLE 5

Identity label	IP address	Domain name	Identity authentication information
				MEP1	IP address	1	Domain name	Account number, password, etc
MEP2	IP address 2	-	Account number, password, etc
				…	…	…	…

In this embodiment, the authentication information of the fourth device may include an identification set (or list) of the fourth device, and the identification set (or list) of the fourth device may include at least one identification of the fourth device. Illustratively, the implementation manner of the identity of the fourth device at least includes a character string or a numerical parameter. When the identity of the fourth device is represented in a character string manner, for example: the different fourth devices are denoted by "schx-MEP1", "schx-MEP2", "hnzdy-MEP". When the identification of the fourth device is expressed by a numerical parameter, for example, "001", "002", "006" indicates a different fourth device.

In this embodiment, the authentication information of the fourth device may include an IP address set (or list) of the fourth device, and the IP address set (or list) of the fourth device may include an IP address of at least one fourth device. Illustratively, the IP address of the fourth device may be implemented at least by means of a character string, for example, the IP address of one fourth device is represented by "117.136.0.22".

In this embodiment, the authentication information of the fourth device may include a domain name set (or list) of the fourth device, and the domain name set (or list) of the fourth device may include at least one domain name of the fourth device. Illustratively, the domain name of the fourth device may be implemented by means of at least a character string, for example, the domain name of one fourth device is represented by "www.cmii-imep1. Cn".

In this embodiment, the authentication information of the fourth device may include an authentication information set (or list) of the fourth device, and the authentication information set (or list) of the fourth device may include authentication information of at least one fourth device, where each authentication information may include, for example, an account name and a password, and is used for authenticating access to one fourth device that can be accessed. Illustratively, the identity authentication information of the fourth device may be implemented by means of at least a character string or a numerical parameter. When the authentication information of the fourth device is implemented by means of a character string, for example, "cmii-imep1" represents an account name of one fourth device, and "asjdkajsew" represents a password of the corresponding fourth device. When the identity authentication information of the fourth device is implemented by means of the numerical parameter, for example, "1234123" represents the account name of one fourth device, and "123141233" represents the password of the corresponding fourth device.

In some optional embodiments of the present application, the method further comprises: and the first equipment sends the capability information to fourth equipment.

In this embodiment, the first device sends the capability information that can be obtained by itself to the fourth device that is accessed, so that the fourth device can obtain the capability information supported by the first device and open to the application on the fourth device for use, thereby implementing a unified supervision function with open capability.

Optionally, when the capability information includes a slice capability identifier, the capability information further includes configuration information of slice parameter templates, the number of slice parameter templates, and an identifier of a slice parameter template.

Optionally, the configuration information of the slice parameter template includes at least one of the following slice parameters and their value ranges:

the maximum number of users is supported by the slice;

slicing a service area;

slicing end-to-end delay;

the moving grade of the terminal in the slice;

slice resource sharing level;

slice reliability requirements.

In some optional embodiments, the method further comprises: the first device receiving a first slice configuration request from the fourth device; the first slice configuration request comprises indication information used for indicating the type of the standard slice parameter template and an identifier of the standard slice parameter template, or comprises indication information used for indicating the type of the custom slice parameter template and custom template parameters; the first device determines a corresponding standard template parameter based on the identifier of the standard slice parameter template, and sends a second slice configuration request to a second device after the standard template parameter or the custom template parameter passes legal check, wherein the second slice configuration request comprises the standard template parameter or the custom template parameter, and the standard template parameter or the custom template parameter is used for the second device to complete the configuration of a network slice; the first device receives a second slice configuration response from the second device, wherein the second slice configuration response comprises a network slice instance identifier; the first device sends a first slice configuration response to the fourth device, wherein the first slice configuration response comprises the network slice instance identifier.

In this embodiment, the fourth device sends a first slice configuration request to the first device based on an application of the application. In this case, the first slice configuration request may include an identifier indicating the standard slice parameter template type and an identifier (or a number) of the standard slice parameter template, or the first slice configuration request may include an identifier indicating the custom slice parameter template type and a custom template parameter. Optionally, in other embodiments, the first slice configuration request may further include at least one of a request type, a request task identifier, and an identity identifier of the first device.

Illustratively, the request type may be represented by a number or a string of characters. In the case where the request type is represented numerically, for example, the slice configuration request may be represented by numeral 1, and the network capability issuing request may be represented by numeral 2. Of course, in the embodiment of the present application, the number is not limited to represent the corresponding request type, and any set number may be used to represent the corresponding request type. In the case where the request type is expressed in a string manner, for example, a slice configuration request is expressed in a string ab, and a network capability issue request is expressed in a string cd. Of course, in the embodiment of the present application, the character string is not limited to be used to represent the corresponding request type, and an arbitrarily set character string may be used to represent the corresponding request type.

In this embodiment, the request task identifier is an identifier of a task uniquely represented in the system.

Illustratively, the identity of the first device may be represented by a string or a number. In this embodiment, the identification may be represented by strings of different formats. For example, the id may be represented by a string in a Universally Unique Identifier (UUID) format. The UUID uses a universally unique identifier standardized by Open Software Foundation (OSF), and a standard version of the UUID includes 32 16 digits, is divided into five segments by a hyphen, and has 32 characters in the form of 8-4-4-4-12, for example, the id can be expressed as: 880e8400-e29b-41d4-a716-446655440000. For another example, the id is identified by a string in NUID format, the NUID uses a UID library of NATS items organized under the Cloud Native Computing Foundation (CNCF), and 62 characters (0-9 a-zA-Z) are used to generate a 22-bit length string, and the result is divided into 2 parts: the first 12 bits are true random numbers and the last 10 bits are pseudo random numbers; for example, the identity may be expressed as: m4bZr, xyO3toV T6iC7lWB. In the case of a digital representation of the identity, the identity may be identified using, for example, a 64-bit integer. Illustratively, snowfall is an algorithm for generating a unique ID in a distributed environment, which is introduced by Twitter, and generates an integer with a size of 64 bits, in this embodiment, the integer with the size of 64 bits may be used to represent an identity, and a Long type is used for storage in a programming language such as Java.

For example, the identifier included in the first slice configuration request for indicating the standard slice parameter template type may be represented by a number or a character string. For example, in the case of numeric representation for indicating the type of the slice parameter template, the standard slice parameter template type may be represented by numeral 0, and the custom slice parameter template type may be represented by numeral 1. Of course, in the embodiment of the present application, the above numbers are not limited to represent the corresponding slice parameter template types, and the arbitrarily set numbers may be used to represent the corresponding slice parameter template types. For another example, when a character string is used to indicate the type of the slice parameter template, the character string "standard" may indicate a standard slice parameter template type, and the character string "custom" may indicate a custom slice parameter template type. Of course, in the embodiment of the present application, the character string is not limited to represent the corresponding slice parameter template type, and an arbitrarily set character string may be used to represent the corresponding slice parameter template type.

In this embodiment, when the first slice configuration request includes a custom template parameter, for example, specific content of the custom template parameter may be as shown in table 6 below. Wherein the parameter SNSSAIList represents the set of S-NSSAIs supported in NSSI. Each S-NSSAI includes one slice/service type (SST) and one optional Slice Discriminator (SD) field, and in the related art, three SSTs are predefined: enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), and large-scale Internet of things (MIoT). The parameter PerfReq sets forth requirements for NSSI such as empirical data rate, area traffic (density) and UE density information, etc., according to the related art.

TABLE 6

Illustratively, the JSON format template corresponding to the above-mentioned custom template parameter is as follows:

the first device judges the authority of the fourth device, and completes validity check on the standard template parameters or the custom template parameters, for example, checks whether unidentifiable parameters exist or whether the parameters exceed a value range, and the like, wherein the validity check is mainly performed on the custom template parameters; after the validity check is completed: under the condition that the type of the slicing parameter template is the standard slicing parameter template type, the first equipment selects the corresponding standard slicing parameter template according to the identification (or the number) of the standard slicing parameter template, and carries the slicing parameter corresponding to the standard slicing parameter template to send a second slicing configuration request to the second equipment; or, when the slice parameter template type is the custom slice parameter template type, the first device carries the custom template parameter and sends a second slice configuration request to the second device. For example, the second slice configuration request includes template parameters (such as standard slice template parameters or custom template parameters), and the second slice configuration request may further include a task identifier, an identity identifier of the second device, and the like. Correspondingly, the first device may send a slice configuration response to the fourth device, where the slice configuration response may include an identity, a reply type, and a reply specification of the fourth device; wherein the reply type indicates whether the slice request was successful.

For example, the above reply type may be represented by referring to table 7 below, and different reply types may be characterized by values of different numbers or character strings, for example, a number 0 may indicate that the slice request is normal, that is, the slice request is successful; the number 1 indicates an illegal identity, i.e. the identity of the fourth device originating the slicing request is illegal; the number 2 indicates a request type error, i.e. a type error requested by a slice configuration request initiated by the fourth device, etc.

TABLE 7

Type of reply	Responsive information specification
		0	Is normal and normal
1	Illegal identity
		2	Request type error
3	Slice parameter type error
		4	Custom template parametersIs out of compliance with the requirements
5	System exception

After the second device interacts with a Communication Service Management Function (CSMF), the second device sends a second slice configuration response to the first device; and the second slice configuration response comprises network slice instance identification. Optionally, the second slice configuration response may further include, in addition to the network slice instance identifier, a reply type, a reply description, and an identity of the first device. Wherein the reply type indicates whether the network slice configuration is successful. Further, the first device sends a first slice configuration response to the fourth device, where the first slice configuration response includes the network slice instance identifier.

For example, as shown in table 8 below, examples of reply types included in the slice configuration response sent by the second device to the first device may refer to, and different reply types may be characterized by values of different numbers or character strings, for example, a number 0 may indicate that the slice configuration is normal, that is, the network slice configuration is successful; numeral 1 indicates an illegal identity, numeral 2 indicates a request type error, and so on.

TABLE 8

Type of reply	Responsive information specification
		0	Is normal
1	Illegal identity
		2	Request type error
3	System exception

Based on the foregoing embodiments, the present application provides a method for acquiring capability openness information. Fig. 3 is a first flowchart illustrating a capability openness information obtaining method according to an embodiment of the present application; as shown in fig. 3, the method includes:

step 201: the third device receives the first request from the first device; the first request is used for requesting capability opening; the first request comprises identity authentication information used for authentication;

step 202: and the third equipment authenticates the first equipment based on the identity authentication information, and sends capability opening information to the first equipment after the authentication is passed.

The capability openness information acquisition method of the embodiment is applied to the third device. Illustratively, the third device is a network capability source, which is a generic name of related networks and systems that can open capability information (or capability data, network capability information or data) to the first device. Illustratively, the third device may be at least one of a RAN, a core network (e.g., 5 GC), or a third party network (e.g., zigbee/Wifi/bluetooth/NB-IoT/wired network, etc.) as shown in fig. 2. The first device is an industry gateway shown in fig. 2, which may also be referred to as a gateway, a gateway device, and the like, and may be denoted as iGW in english. The names of the first device and the third device are not limited in the embodiment of the present application, as long as the respective functions of the first device and the third device can be implemented.

In this embodiment, the third device receives a first request sent by the first device, where the first request is used to request the capability to be opened, that is, to request the third device to open the capability. The first request comprises identity authentication information used for authentication and is used for being sent to third equipment for local authentication.

In some optional embodiments, the sending the capability openness information to the first device includes: and the third equipment opens a capability application programming interface, and sends capability opening information to the first equipment based on the opened capability application programming interface.

In this embodiment, after the third device passes authentication based on the identity authentication information, the third device may send capability opening information to the first device through an open capability API (which may also be referred to as a network capability API) and through an open capability API interface.

In some optional embodiments, the method further comprises: transmitting a message between the third device and the first device; terminating opening the capability application programming interface to the first device if the third device does not receive a message from the first device.

In this embodiment, for example, after the first device sends the first request and the third device opens the capability API, the third device determines to continue to open the capability API or terminate the capability API by transmitting a message between the first device and the third device. Wherein the transmitted message may also be referred to as a heartbeat message.

In one embodiment, the first device continuously sends a message to the third device, and if the third device receives the message sent by the first device and determines that the communication link with the first device is normal, the third device may continue to open the capability API; correspondingly, if the third device does not receive the message sent by the first device, it may be determined that the communication link with the first device is abnormal, and it may be determined that the open capability API is terminated. In another embodiment, the third device may send a message to the first device, and after receiving the message sent by the first device, the third device returns a message to the third device; if the third device receives a message returned by the third device within a preset time range, the communication link with the first device can be determined to be normal, and the capability API can be continuously opened; correspondingly, if the third device does not receive the message returned by the third device within the preset time range, and it can be determined that the communication link with the first device is abnormal, it can be determined that the open capability API is terminated.

In some optional embodiments, the method further comprises: the third equipment authenticates the first equipment through the second equipment; and the third equipment sends capability information to the second equipment, wherein the capability information is used for indicating the capability which can be obtained by the first equipment, and the capability information is sent after the first equipment is authenticated.

In this embodiment, before the first device requests the third device for capability opening, a multi-level access authentication process needs to be performed among the first device, the second device, and the fourth device. Here, the first device first initiates access authentication to the second device, that is, the first device sends a first access authentication request to the second device to determine whether the first device has the right to access the system; after determining that the first device has the authority to access the system, the first device can be determined to finish accessing the system, and the second device sends a first access authentication response to the first device. In this case, the second device may complete an authentication procedure with the third device for the first device according to the capability information supported by the first device reported when the first device requests access, and for example, the third device may determine whether the first device can obtain the capability information opened by the third device according to the capability information supported by the first device reported by the first device. After the third device passes the authentication of the first device, the third device sends the capability information to the second device, and after the first device requests the capability information from the second device, the second device sends the capability information to the first device.

Optionally, the capability information includes at least one of the following information: the capability identifier, the type information of the third device, the domain name of the third device, the Internet Protocol (IP) address of the third device, and the identity authentication information of the third device.

Illustratively, the capability identification includes at least one of: location service capability identification, wireless network information service capability identification, monitoring capability identification, pre-configuration capability identification and strategy/charging capability identification.

Illustratively, the wireless network information service capability identification includes at least one of: the system comprises a wireless access network information identifier, a slicing capability identifier, an access user capability identifier, a multi-mode network access identifier and a data statistics report capability identifier.

Illustratively, the type information of the third device includes at least one of: a wireless access network identifier, a network function identifier of a core network, and a third-party system identifier.

In this embodiment, the third device may send the capability information to the second device through information or control signaling, where the capability information may also be network capability information. Illustratively, the capability information is a set of information, which may also be referred to as a capability information list or a network capability information list. Specifically, the specific content of the capability information may refer to the content described in the foregoing embodiments, and is not described herein again.

Based on the above embodiments, the present application provides a capability openness information obtaining method. Fig. 5 is a third schematic flow chart of a capability openness information acquisition method according to an embodiment of the present application; as shown in fig. 5, the method includes:

step 301: the second device receives a second request from the first device, wherein the second request is used for requesting the capability information;

step 302: and the second equipment sends the capability information to the first equipment, wherein the capability information is used for indicating the capability which can be obtained by the first equipment.

The capability openness information acquiring method of the embodiment is applied to the second device. Illustratively, the second device may be a management system or an operation system, such as a BSS/OSS. The name of the second device is not limited in the embodiment of the present application, as long as the function of the second device can be realized.

Optionally, the capability information includes at least one of the following information: the device comprises a capability identifier, type information of the third device, a domain name of the third device, an Internet Protocol (IP) address of the third device and identity authentication information of the third device.

In this embodiment, the second device may send the capability information through information or control signaling, where the capability information may also be network capability information. Illustratively, the capability information is a set of information, which may also be referred to as a capability information list or a network capability information list. Specifically, the capability information may refer to the description in the foregoing embodiments, and is not described herein again.

In some optional embodiments of the present application, the method further comprises: the second equipment receives a first access authentication request from the first equipment, wherein the first access authentication request comprises authentication requirement information and capability information supported by the first equipment; after the second device passes the authentication of the first device, sending a first access authentication response to the first device, wherein the first access authentication response comprises authentication information of a fourth device; and the authentication information of the fourth equipment is used for the fourth equipment to access the first equipment.

In this embodiment, before the first device requests the third device for capability opening, a multi-level access authentication process needs to be performed among the first device, the second device, and the fourth device. Here, the first device first initiates access authentication to the second device to determine whether the first device has the authority to access the system; after determining that the first device has the authority to access the system, it may be determined that the first device has completed accessing the system, and the first device obtains an access authentication response from the second device, where the access authentication response includes authentication information of the fourth device, so that, after the fourth device initiates an access request to the first device, the first device may locally authenticate the fourth device initiating the access request based on the authentication information of the fourth device included in the authentication response, and after the authentication passes, it may be determined that the fourth device completes accessing the first device.

Optionally, the second device may receive the first access authentication request from the first device through a message, information, or signaling, so as to obtain the authentication requirement information reported by the first device and the capability information supported by the first device through the first access authentication request.

For example, the authentication requirement information may also be referred to as access authentication requirement information. For example, the authentication requirement information may be represented by an authentication requirement identifier, that is, the first access authentication request includes the authentication requirement representation, which indicates that the message, information, or signaling is used to request access authentication.

In some optional embodiments, the list of capability information supported by the first device comprises at least one of: the identification of the first device, the type of the network that the first device supports access, an indication of whether the first device supports network capability opening, an indication of whether the first device indicates internet security protocol IPSec, performance information of the first device, and an indication of whether the first device supports wide area interconnection.

For the capability information supported by the first device in this embodiment, reference may be specifically made to the description in the foregoing embodiment, and details are not described here again.

In this embodiment, the second device authenticates the first device, and after determining that the first device has the authority to access the system, sends a first access authentication response to the second device; the first access authentication response comprises authentication information of each fourth device capable of accessing the first device, and the authentication response of the fourth device is used for the first device to perform local authentication on the fourth device requesting access.

In some optional embodiments, the authentication information of the fourth device comprises at least one of: the identity of the fourth device, the IP address of the fourth device, the domain name of the fourth device, and the identity authentication information of the fourth device.

The authentication information of the fourth device in this embodiment may specifically refer to the authentication information in the foregoing embodiment, and is not described herein again.

The embodiment of the application provides a capability openness information acquisition method. Fig. 6 is a schematic flowchart of a capability openness information acquisition method according to an embodiment of the present application; as shown in fig. 6, the method includes:

step 401: the fourth device receives capability information from the first device, wherein the capability information is used for indicating the capability which can be obtained by the first device;

step 402: and the fourth equipment processes the corresponding capacity based on the capacity information.

The capability openness information acquiring method of the present embodiment is used in a fourth device, which may be, for example, an MEP shown in fig. 2 and may also be referred to as an MEC platform, an MEC server, or the like. The name of the fourth device is not limited in the embodiment of the present application, as long as the function of the fourth device can be realized.

In this embodiment, the first device sends the capability information that can be obtained by itself to the fourth device that is accessed, so that the fourth device can obtain the capability information supported by the first device and open to the application on the fourth device for use, thereby implementing a unified supervision function with open capability. Illustratively, the fourth device may obtain the capability information through an API provided by the first device.

In some optional embodiments of the present application, the fourth device receives capability information from the first device, including: the agent function component of the fourth device performs information interaction with the first device and receives network capability information from the first device; correspondingly, the fourth device performs corresponding processing based on the capability information, including: and the application component of the fourth device carries out corresponding processing based on the network capability information.

Optionally, the capability information includes at least one of the following information: the capability identifier, the type information of the third device, the domain name of the third device, the IP address of the third device, and the identity authentication information of the third device.

In this embodiment, the capability information may refer to specific descriptions in the foregoing embodiments, and details are not described here.

Optionally, the capability identification comprises at least one of: location service capability identification, wireless network information service capability identification, monitoring capability identification, pre-configuration capability identification and strategy/charging capability identification; wherein the wireless network information service capability identification comprises at least one of: the system comprises a wireless access network information identifier, a slicing capability identifier, an access user capability identifier, a multi-standard network access identifier and a data statistics report capability identifier.

Optionally, the type information of the third device includes at least one of: a wireless access network identifier, a network function identifier of a core network, and a third-party system identifier.

In this embodiment, the fourth device may obtain the capability information through an API provided by the first device; illustratively, the capability information is a set of information, which may also be referred to as a capability information list or a network capability information list.

For example, the capabilities that the first device can obtain include, but are not limited to, UE event monitoring capability, pre-configuration capability, routing policy configuration capability, data statistics reporting capability, radio access network information, network slicing capability, positioning capability (e.g., 5G, wiFi, bluetooth, or GPS), positioning data, access user capability, multi-mode network access capability, quality of Service (QoS) capability, and the like.

In some optional embodiments, in a case that the wireless network information service capability identifier includes an access user capability identifier, the fourth device performs, based on the capability information, processing of a corresponding capability, including: and the fourth equipment manages the accessed user based on the access user capacity identification.

Optionally, the method further comprises: the fourth device sends at least one of the following information to the first device: the mobile phone number of the access user, the user name of the access user, the IP address of the access user and the access application identification.

In this embodiment, the fourth device can manage the user accessing the fourth device through the user accessing capability provided by the first device, and further, the information that the fourth device can send to the first device includes, but is not limited to, at least one of the following: the mobile phone number of the access user, the user name of the access user, the IP address of the access user and the access application identification (such as application ID).

In some optional embodiments, in a case that the wireless network information service capability identifier includes a slice capability identifier, the capability information further includes configuration information of slice parameter templates, the number of slice parameter templates, and an identifier of a slice parameter template; the configuration information of the slice parameter template includes at least one of the following slice parameters and their value ranges:

the slice supports the maximum number of users;

slicing a service area;

slicing end-to-end delay;

the moving grade of the terminal in the slice;

slice resource sharing level;

slice reliability requirements.

Optionally, the fourth device performs processing of corresponding capability based on the capability information, including: the fourth device sends a first slice configuration request to the first device, wherein the first slice configuration request comprises indication information used for indicating a standard slice parameter template type or indication information used for indicating a self-defined slice parameter template type and a self-defined template parameter; the fourth device receives a first slice configuration response from the first device, wherein the first slice configuration response comprises the network slice instance identification.

In this embodiment, the fourth device sends a first slice configuration request to the first device based on an application of the application. In this case, the first slice configuration request may include an identifier indicating the standard slice parameter template type and an identifier (or number) indicating the standard slice parameter template, or the first slice configuration request may include an identifier indicating the custom slice parameter template type and a custom template parameter. Optionally, in other embodiments, the first slice configuration request may further include at least one of a request type, a request task identifier, and an identity identifier of the first device.

The first device judges the authority of the fourth device, and completes validity check on the standard template parameters or the custom template parameters, for example, checks whether unidentifiable parameters exist or whether the parameters exceed a value range, and the like, wherein the validity check is mainly performed on the custom template parameters; after the validity check is completed: under the condition that the type of the slicing parameter template is the standard slicing parameter template type, the first equipment selects the corresponding standard slicing parameter template according to the identification (or the number) of the standard slicing parameter template, and carries the slicing parameter corresponding to the standard slicing parameter template to send a second slicing configuration request to the second equipment; or, when the slice parameter template type is the custom slice parameter template type, the first device carries the custom template parameter and sends a second slice configuration request to the second device. For example, the second slice configuration request includes template parameters (such as standard slice template parameters or custom template parameters), and the second slice configuration request may further include a task identifier, an identity identifier of the second device, and the like.

After the second device interacts with the CSMF to complete the actual configuration of the slice, a second slice configuration response is sent to the first device; and the second slice configuration response comprises network slice instance identification. Optionally, the second slice configuration response may further include, in addition to the network slice instance identifier, a reply type, a reply description, and an identity of the first device. Wherein the reply type indicates whether the network slice configuration is successful. Further, the first device sends a first slice configuration response to the fourth device, where the first slice configuration response includes the network slice instance identifier.

In some optional embodiments of the present application, the method further comprises: the fourth device receives a broadcast message from the first device; based on the broadcast message, the fourth device sends a second access authentication request to the first device; the second access authentication request is used for the first equipment to perform access authentication on the fourth equipment; receiving a second access authentication response from the first device.

In this embodiment, before the first device requests the third device for capability opening, a multi-level access authentication process needs to be performed among the first device, the second device, and the fourth device. Here, the first device first initiates access authentication to the second device to determine whether the first device has the authority to access the system; after determining that the first device has the authority to access the system, determining that the access of the first device to the system is completed, wherein the first device obtains a first access authentication response from the second device, and the first access authentication response comprises authentication information of the fourth device; the first equipment sends a broadcast message; after the fourth device that receives the broadcast message initiates the second access authentication request to the first device, the first device may locally authenticate the fourth device that initiates the access request based on authentication information of the fourth device included in the authentication response, and after the authentication is passed, it may be determined that the fourth device completes accessing the first device, and then the first device sends the second access authentication response to the fourth device.

Fig. 7 is a schematic diagram of a network capability open architecture of cloud network convergence in the industry 5G of the application embodiment of the present application; as shown in fig. 7, the first device (i.e., the industry gateway) actually serves as a network capability openness function proxy between the MEP and the RAN, between the MEP and the 5GC, and between the MEP and a third-party system (which may include a third-party network and third-party network capabilities), and the industry gateway may open network capability information (or capability openness information) to the MEP based on the network capability openness performed by the industry gateway through a proxy manner.

Fig. 8 is a schematic diagram of an MEP capability open function architecture according to an embodiment of the present application; as shown in fig. 8, an MEP (i.e., a fourth device) is provided with an Agent function component, and is in butt joint with an industry gateway (i.e., a first device), that is, the Agent function component may be denoted as iGW-Agent function component, so that the fourth device obtains capability information supported by the first device, and is opened uniformly for an Application (APP) on the MEP to use, thereby realizing a uniform supervision function of opening network capability.

By adopting the technical scheme of the embodiment of the application, on the first hand, the embodiment of the application realizes that the industry gateway (namely, the first device) can acquire the capability opening information from the third device (namely, the capability source, such as RAN, 5GC and a third-party network).

In the second aspect, the connection state between the first device and the third device is detected through the heartbeat message, so that a redundancy mechanism for acquiring the capability opening information by the first device is realized.

And in the third aspect, the normal connection and information interaction of each functional module under the architecture of the industry cloud network fusion system are ensured based on the multi-level access authentication scheme of the industry gateway so as to support the subsequent interaction of network open information.

In a fourth aspect, on the basis of an industry cloud network convergence architecture, unified configuration and supervision of opening of network capabilities on an MEP are achieved through interaction among the MEP, an industry gateway and an OSS, and the MEP is supported to achieve self-service network management functions such as access user management and configuration of network slices through the industry gateway.

The following describes a capability opening method according to an embodiment of the present application with reference to a specific example. In the following examples, the first device is taken as an industry gateway, the second device is taken as a BSS/OSS, the third device is taken as a capability source, and the fourth device is taken as an MEP.

Example 1

Fig. 9 is an interaction flow diagram of a capability openness information acquisition method according to an embodiment of the present application; as shown in fig. 9, the method includes:

step 501: and completing multi-stage access authentication among the industry gateway, the BSS/OSS and the MEP.

Here, the multi-stage access process includes steps of reporting the authentication requirement and the supported capability information list when the industry gateway accesses the BSS/OSS, and the BSS/OSS issuing MEP authentication information to the industry gateway.

It should be noted that the MEP is not shown in the figure, and the detailed description of the multi-level access process can be referred to as example two.

Step 502: the BSS/OSS completes the authentication process with the capability source according to the capability information supported by the industry gateway reported when requesting access, and obtains a capability information list (i.e., the capability information that can be obtained by the first device in the above embodiment).

Here, the capability sources include RAN, 5GC, third party network, and the like.

Illustratively, the capability information list includes at least one of the following information: capability identification, type information of the capability source, domain name of the capability source, IP address of the capability source and identity authentication information of the capability source.

Step 503: the industry gateway requests a capability information list from the BSS/OSS to learn the capabilities that it can obtain.

Step 504: and the BSS/OSS transmits a capability information list to the industry gateway.

Step 505: the industry gateway requests the capability source for capability opening (that is, the first device sends the first request to the third device in the foregoing embodiment) according to the capability information list issued by the BSS/OSS.

Here, the capability opening request includes authentication information (e.g., an account name and a password) for authentication

Step 506: the capability source locally authenticates the identity of the industry gateway requesting the network capability to be open. After the authentication is passed, step 507 is performed.

And the capability source verifies the identity authentication information carried in the capability opening request according to the identity authentication information interacted with the BSS/OSS, and after the verification is passed, the identity authentication of the industry gateway is determined to be passed.

Step 507: the capability source opens a capability API to the industry gateway.

Step 508: and the industry gateway transmits heartbeat messages for maintaining network capability interaction with the capability source opening.

If the heartbeat message is successfully maintained, step 512 is entered, and the network capability opening procedure is entered.

In case the heartbeat message fails to maintain, step 509 is entered.

Step 509: the heartbeat maintenance fails and the capability source terminates the opening of the capability API to the industry gateway.

Step 510: and the industry gateway reports fault information indicating that the network capability acquisition fails to the BSS/OSS and requests an indication of the next action.

Step 511: and the BSS/OSS issues fault repair information to the industry gateway to indicate and support the industry gateway to restart to acquire capacity opening information from the capacity source.

Step 512: the industry gateway obtains capability openness information from a capability source based on an open capability API.

Example two

Fig. 10 is a schematic view illustrating an access authentication interaction flow in a capability openness information acquisition method according to an embodiment of the present application; as shown in fig. 10, the method includes:

step 601: and the industry gateway initiates an access authentication request to the BSS/OSS, and reports authentication demand information and a capability information list supported by the industry gateway.

Here, the access authentication request is the first access authentication request in the foregoing embodiment.

Step 602: and the BSS/OSS authenticates the industry gateway, judges whether the industry gateway has the authority of accessing the system, and executes the subsequent steps after the authentication is passed.

Step 603: and the BSS/OSS sends an access authentication response to the industry gateway.

Here, the access authentication response is the first access authentication response in the foregoing embodiment; the access authentication response comprises authentication information of the MEP accessing the industry gateway, and the authentication information of the MEP comprises an MEP identity identification list (which can comprise one or more MEP identities) allowing the industry gateway to be accessed, the authority level of each MEP and other MEP related configuration information.

Step 604: the industry gateway initiates a broadcast whose role is to indicate that it is in an accessible state.

Step 605: and the MEP sends an access request to the industry gateway after receiving the broadcast of the industry gateway.

Here, the access request is the second access authentication request in the foregoing embodiment.

Step 606: and the industry gateway performs local authentication on the MEP requesting access according to the authentication information of the MEP issued by the BSS/OSS.

Step 607: and the industry gateway issues an access response to the MEP which passes the authentication.

Here, the access response is the second access authentication response in the foregoing embodiment, and the second received authentication response indicates that the MEP is authenticated.

Step 608: after the access authentication of the industry gateway, the capability source, the BSS/OSS, and the MEP is successful, the process of capability opening as in example one can be entered.

Example three

Fig. 11 is a schematic view illustrating a slice configuration flow in a capability openness information acquisition method according to an embodiment of the present application; as shown in fig. 11, the method includes:

step 701: the MEP sends a slice configuration request to the industry gateway.

Here, the slice configuration request is the first slice configuration request in the foregoing embodiment. Illustratively, the slice configuration request may include a request type (which may be used to indicate the slice configuration request), a request task ID, an identification of an industry gateway, a slice parameter template type (which may be used to indicate a standard slice parameter template type or a custom slice parameter template type); if the standard slice parameter template type is available, the slice configuration request also comprises a standard template number; and if the type of the self-defined slice parameter template is the self-defined slice parameter template type, the slice configuration request also comprises self-defined template parameters.

Step 702: and the industry gateway checks the authority of the MEP and checks the legality of the carried parameters based on the slice configuration request.

Here, the industry gateway mainly performs validity check on the custom template parameters. For example, whether there is an unidentifiable parameter, whether the parameter exceeds a value range, and the like are checked.

Step 703: the industry gateway sends a slice configuration request to the OSS.

Here, the slice configuration request is the second slice configuration request in the foregoing embodiment. Illustratively, the slice configuration request may include a request type (which may be used to indicate the slice configuration request), a request task ID, an identification of the OSS, slice template parameters, and the like.

Step 704: and the OSS sends a slice configuration response to the industry gateway, wherein the slice configuration response comprises a slice instance ID.

Here, after the OSS and the CSMF interact to complete the actual configuration of the network slice, send a slice configuration response to the industry gateway, where the slice configuration response is the second slice configuration response in the foregoing embodiment. Illustratively, the slice configuration response may include a reply type (indicating whether the slice configuration is successful), a reply description (corresponding to the reply type one by one), an identity of the first device, a slice instance ID (indicating a number of the network slice in the system), and the like.

Step 705: and the industry gateway sends a slice configuration response to the MEP, wherein the slice configuration response comprises a slice instance ID.

Here, the slice configuration response is the first slice configuration response in the foregoing embodiment.

The embodiment of the application also provides a capability openness information acquisition device. Fig. 12 is a schematic structural diagram of a first configuration of a capability openness information acquiring apparatus according to an embodiment of the present application, and as shown in fig. 12, the apparatus includes: a first transmitting unit 11 and a first receiving unit 12; wherein the content of the first and second substances,

the first sending unit 11 is configured to send a first request to a third device; the first request is used for requesting capability opening; the first request comprises identity authentication information used for authentication;

the first receiving unit 12 is configured to obtain capability opening information from the third device; the capability opening information is obtained after the identity authentication information is authenticated by the third equipment.

In some optional embodiments of the present application, the first sending unit 11 is further configured to send a second request to the second device, where the second request is used to request capability information; the capability information is used for indicating the capability which can be obtained by the first equipment;

the first receiving unit 12 is further configured to receive the capability information from the second device.

In some optional embodiments of the present application, the capability information includes at least one of the following information: the capability identification, the type information of the third device, the domain name of the third device, the IP address of the third device, and the identity authentication information of the third device.

In some optional embodiments of the present application, the capability identification comprises at least one of: location service capability identification, wireless network information service capability identification, monitoring capability identification, pre-configuration capability identification and policy/charging capability identification.

In some optional embodiments of the present application, the wireless network information service capability identification comprises at least one of: the system comprises a wireless access network information identifier, a slicing capability identifier, an access user capability identifier, a multi-standard network access identifier and a data statistics report capability identifier.

In some optional embodiments of the present application, the type information of the third device comprises at least one of: a wireless access network identifier, a network function identifier of a core network, and a third-party system identifier.

In some optional embodiments of the present application, the first sending unit 11 is further configured to send, to the second device, first information in a case that the first receiving unit 12 cannot acquire the capability opening information from the third device, where the first information is used to indicate a capability acquisition failure;

the first receiving unit 12 is further configured to receive second information from the second device, where the second information includes capability acquisition fault repair information.

In some optional embodiments of the present application, the apparatus further comprises a first processing unit 13;

the first sending unit 11 is further configured to send a first access authentication request to the second device, where the first access authentication request includes authentication requirement information and capability information supported by the first device;

the first receiving unit 12 is further configured to receive a first access authentication response from the second device, where the first access authentication response includes authentication information of a fourth device;

the first sending unit 11 is further configured to send a broadcast message based on the authentication information of the fourth device; the broadcast message is used for the fourth equipment which receives the broadcast message to initiate access authentication;

the first receiving unit 12 is further configured to receive a second access authentication request from a fourth device;

the first processing unit 13 is configured to authenticate the fourth device based on the authentication information of the fourth device;

the first sending unit 11 is further configured to send a second access authentication response to the fourth device after the first processing unit 13 authenticates the fourth device.

In some optional embodiments of the present application, the capability information supported by the first device comprises at least one of the following information: an identity of the first device, a network type that the first device supports access, an indication of whether the first device supports capability openness, an indication of whether the first device indicates internet security protocol (IPSec), capability information of the first device, and an indication of whether the first device supports wide area interconnection.

In some optional embodiments of the present application, the performance information of the first device comprises at least one of: interface bandwidth of the first device, and a number of fourth devices supported by the first device.

In some optional embodiments of the present application, the authentication information of the fourth device comprises at least one of: the identity of the fourth device, the IP address of the fourth device, the domain name of the fourth device, and the identity authentication information of the fourth device.

In some optional embodiments of the present application, the first sending unit 11 is further configured to send the capability information to a fourth device.

In some optional embodiments of the present application, in a case that the capability information includes a slice capability identifier, the capability information further includes configuration information of slice parameter templates, the number of slice parameter templates, and an identifier of a slice parameter template.

In some optional embodiments of the present application, the configuration information of the slice parameter template includes a slice parameter and a value range thereof, where the slice parameter includes at least one of the following:

the maximum number of users is supported by the slice;

slicing a service area;

slicing end-to-end delay;

the moving grade of the terminal in the slice;

slice resource sharing level;

slice reliability requirements.

the first receiving unit 12 is further configured to receive a first slice configuration request from the fourth device; the first slice configuration request comprises indication information used for indicating the type of the standard slice parameter template and an identifier of the standard slice parameter template, or comprises indication information used for indicating the type of the custom slice parameter template and custom template parameters;

the first processing unit 13 is configured to determine a corresponding standard template parameter based on the identifier of the standard slice parameter template, and perform a legal check on the standard template parameter or the custom template parameter;

the first sending unit 11 is further configured to send, after the first processing unit 13 passes the legal check on the standard template parameter or the custom template parameter, a second slice configuration request to a second device, where the second slice configuration request includes the standard template parameter or the custom template parameter, and the standard template parameter or the custom template parameter is used for the second device to complete the configuration of a network slice;

the first receiving unit 12 is further configured to receive a second slice configuration response from the second device, where the second slice configuration response includes a network slice instance identifier;

the first sending unit 11 is further configured to send a first slice configuration response to the fourth device, where the first slice configuration response includes the network slice instance identifier.

In the embodiment of the application, the device is applied to the first equipment. The first Processing Unit 13 in the device may be implemented by a Central Processing Unit (CPU), a Digital Signal Processor (DSP), a Micro Control Unit (MCU) or a Programmable Gate Array (FPGA) in practical application; the first sending unit 11 and the first receiving unit 12 in the device can be realized by a communication module (including a basic communication suite, an operating system, a communication module, a standardized interface, a protocol and the like) and a transceiving antenna in practical application.

The embodiment of the application also provides a capability openness information acquisition device. Fig. 13 is a schematic structural diagram of a second configuration of a capability openness information acquiring apparatus according to an embodiment of the present application, and as shown in fig. 13, the apparatus includes: a second receiving unit 21, a second processing unit 22, and a second transmitting unit 23; wherein the content of the first and second substances,

the second receiving unit 21 is configured to receive a first request from a first device; the first request is used for requesting capability opening; the first request comprises identity authentication information used for authentication;

the second processing unit 22 is configured to authenticate the first device based on the identity authentication information;

the second sending unit 23 is configured to send capability opening information to the first device after the second processing unit 22 passes the authentication.

In some optional embodiments of the present application, the second processing unit 22 is further configured to use an open capability application programming interface;

the second sending unit 23 is configured to send capability opening information to the first device based on the opened capability application programming interface.

In some optional embodiments of the present application, the second processing unit 22 is configured to transmit a message with the first device through the second sending unit 23 and the second receiving unit 21; in case no message from the first device is received through the second receiving unit 21, the opening of the capability application programming interface to the first device is terminated.

In some optional embodiments of the present application, the apparatus further comprises a first authentication unit, configured to authenticate the first device through a second device;

the second sending unit 23 is further configured to send capability information to the second device, where the capability information is used to indicate a capability that the first device can obtain, and the capability information is sent after the first authentication unit authenticates the first device.

In some optional embodiments of the present application, the capability information includes at least one of the following information: the capability identifier, the type information of the third device, the domain name of the third device, the Internet Protocol (IP) address of the third device, and the identity authentication information of the third device.

In some optional embodiments of the application, the type information of the third device comprises at least one of: a wireless access network identifier, a network function identifier of a core network, and a third-party system identifier.

In the embodiment of the application, the device is applied to the third equipment. The second processing unit 22 and the first authentication unit in the device can be realized by a CPU, a DSP, an MCU or an FPGA in practical application; the second sending unit 23 and the second receiving unit 21 in the device can be realized by a communication module (including a basic communication suite, an operating system, a communication module, a standardized interface, a protocol and the like) and a transceiving antenna in practical application.

The embodiment of the application also provides a capability openness information acquisition device. Fig. 14 is a schematic structural diagram of a third component of the capability openness information acquiring apparatus according to the embodiment of the present application, and as shown in fig. 14, the apparatus includes: a third receiving unit 32 and a third transmitting unit 31; wherein, the first and the second end of the pipe are connected with each other,

the third receiving unit 32 is configured to receive a second request from the first device, where the second request is used to request capability information;

the third sending unit 31 is configured to send the capability information to the first device, where the capability information is used to indicate capabilities that can be obtained by the first device.

In some optional embodiments of the present application, the capability information includes at least one of the following information: the device comprises a capability identifier, type information of the third device, a domain name of the third device, an Internet Protocol (IP) address of the third device and identity authentication information of the third device.

In some optional embodiments of the present application, the wireless network information service capability identifier includes at least one of: the system comprises a wireless access network information identifier, a slicing capability identifier, an access user capability identifier, a multi-standard network access identifier and a data statistics report capability identifier.

In some optional embodiments of the present application, the third receiving unit 32 is further configured to receive a first access authentication request from the first device, where the first access authentication request includes authentication requirement information and capability information supported by the first device;

the third sending unit 31 is further configured to send a first access authentication response to the first device after the authentication of the first device is passed, where the first access authentication response includes authentication information of a fourth device; and the authentication information of the fourth equipment is used for the fourth equipment to access the first equipment.

In some optional embodiments of the present application, the list of capability information supported by the first device comprises at least one of: an identity of the first device, a network type that the first device supports access, an indication of whether the first device supports network capability opening, an indication of whether the first device indicates internet security protocol (IPSec), capability information of the first device, and an indication of whether the first device supports wide area interconnection.

In some optional embodiments of the application, the performance information of the first device comprises at least one of: interface bandwidth of the first device, and a number of fourth devices supported by the first device.

In the embodiment of the application, the device is applied to the second equipment. The third sending unit 31 and the third receiving unit 32 in the device can be realized by a communication module (including a basic communication suite, an operating system, a communication module, a standardized interface, a protocol and the like) and a transceiving antenna in practical application.

The embodiment of the application also provides a capability openness information acquisition device. Fig. 15 is a schematic structural diagram of a fourth configuration of the capability openness information acquiring apparatus according to the embodiment of the present application, and as shown in fig. 15, the apparatus includes: a fourth receiving unit 41 and a fourth processing unit 42; wherein the content of the first and second substances,

the fourth receiving unit 41 is configured to receive capability information from a first device, where the capability information is used to indicate capabilities that can be obtained by the first device;

the fourth processing unit 42 is configured to perform processing of the corresponding capability based on the capability information.

In some optional embodiments of the present application, the fourth receiving unit 41 is configured to perform information interaction with the first device through a proxy function component, and receive capability information from the first device;

the fourth processing unit 42 is configured to perform corresponding processing based on the capability information through an application component.

In some optional embodiments of the present application, the capability identification comprises at least one of: location service capability identification, wireless network information service capability identification, monitoring capability identification, pre-configuration capability identification and strategy/charging capability identification;

wherein the wireless network information service capability identifier comprises at least one of: the system comprises a wireless access network information identifier, a slicing capability identifier, an access user capability identifier, a multi-standard network access identifier and a data statistics report capability identifier.

The fourth processing unit 42 is configured to, in a case that the wireless network information service capability identifier includes an access user capability identifier, manage an access user based on the access user capability identifier.

In some optional embodiments of the present application, the apparatus further comprises a fourth sending unit 43, configured to send at least one of the following information to the first device: the mobile phone number of the access user, the user name of the access user, the IP address of the access user and the access application identification.

In some optional embodiments of the present application, in a case that the wireless network information service capability identifier includes a slice capability identifier, the capability information further includes configuration information of a slice parameter template, the number of slice parameter templates, and an identifier of the slice parameter template;

the maximum number of users is supported by the slice;

slicing a service area;

slicing end-to-end delay;

the mobile level of the terminal in the slice;

slice resource sharing level;

slice reliability requirements.

In some optional embodiments of the present application, the fourth processing unit 42 is configured to send, to the first device through the fourth sending unit 43, a first slice configuration request, where the first slice configuration request includes indication information for indicating a standard slice parameter template type or indication information for indicating a custom slice parameter template type and a custom template parameter; receiving, by the fourth receiving unit 41, a first slice configuration response from the first device, where the first slice configuration response includes the network slice instance identifier.

In some optional embodiments of the present application, the fourth receiving unit 41 is further configured to receive a broadcast message from the first device;

the fourth sending unit 43 is further configured to send a first access authentication request to the first device based on the broadcast message; the first access authentication request is used for the first device to authenticate the fourth device;

the fourth receiving unit 41 is further configured to receive a second access authentication response from the first device.

In the embodiment of the present application, the apparatus is applied to a fourth device. The fourth processing unit 42 in the device can be realized by a CPU, a DSP, an MCU or an FPGA in practical application; the fourth transmitting unit 43 and the fourth receiving unit 41 of the device can be realized by a communication module (including a basic communication suite, an operating system, a communication module, a standardized interface, a standardized protocol and the like) and a transceiving antenna in practical application.

It should be noted that: in the capacity openness information acquiring apparatus provided in the above embodiment, when acquiring the capacity openness information, only the division of each program module is illustrated, and in practical applications, the above processing distribution may be completed by different program modules according to needs, that is, the internal structure of the apparatus is divided into different program modules, so as to complete all or part of the above-described processing. In addition, the capability openness information acquiring apparatus and the capability openness information acquiring method provided in the above embodiments belong to the same concept, and specific implementation processes thereof are described in detail in the method embodiments, and are not described herein again.

The embodiment of the present application further provides a communication device, where the communication device is the first device, the second device, the third device, or the fourth device in the foregoing embodiments. Fig. 16 is a schematic diagram of a hardware structure of a communication device according to an embodiment of the present application, and as shown in fig. 16, the communication device includes a memory 52, a processor 51 and a computer program stored in the memory 52 and executable on the processor 51, and when the processor 51 executes the computer program, the processor 51 implements the steps of the capability openness information obtaining method applied to the first device according to the embodiment of the present application; or, the processor 51 implements the step of the capability openness information obtaining method applied to the second device in the embodiment of the present application when executing the program; or, the processor 51 implements the step of the capability openness information obtaining method applied to the third device in the embodiment of the present application when executing the program; or, the processor 51 implements the steps of the capability openness information obtaining method applied to the fourth device in the embodiment of the present application when executing the program.

Optionally, one or more network interfaces 53 may also be included in the communication device. It will be appreciated that the various components of the communication device are coupled together by a bus system 54. It will be appreciated that the bus system 54 is used to enable communications among the connections between these components. The bus system 54 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled as bus system 54 in fig. 16.

It will be appreciated that the memory 52 can be either volatile memory or nonvolatile memory, and can include both volatile and nonvolatile memory. Among them, the nonvolatile Memory may be a Read Only Memory (ROM), a Programmable Read Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a magnetic random access Memory (FRAM), a magnetic random access Memory (Flash Memory), a magnetic surface Memory, an optical Disc, or a Compact Disc Read-Only Memory (CD-ROM); the magnetic surface storage may be disk storage or tape storage. Volatile Memory can be Random Access Memory (RAM), which acts as external cache Memory. By way of illustration and not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), synchronous Static Random Access Memory (SSRAM), dynamic Random Access Memory (DRAM), synchronous Dynamic Random Access Memory (SDRAM), double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), enhanced Synchronous Dynamic Random Access Memory (ESDRAM), enhanced Synchronous Dynamic Random Access Memory (Enhanced DRAM), synchronous Dynamic Random Access Memory (SLDRAM), direct Memory (DRmb Access), and Random Access Memory (DRAM). The memory 52 described in the embodiments of the present application is intended to comprise, without being limited to, these and any other suitable types of memory.

The method disclosed in the embodiment of the present application may be applied to the processor 51, or may be implemented by the processor 51. The processor 51 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware or instructions in the form of software in the processor 51. The processor 51 described above may be a general purpose processor, a DSP, or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. The processor 51 may implement or perform the methods, steps and logic blocks disclosed in the embodiments of the present application. A general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium located in the memory 52, and the processor 51 reads the information in the memory 52 and performs the steps of the aforementioned method in conjunction with its hardware.

In an exemplary embodiment, the communication Device may be implemented by one or more Application Specific Integrated Circuits (ASICs), DSPs, programmable Logic Devices (PLDs), complex Programmable Logic Devices (CPLDs), FPGAs, general purpose processors, controllers, MCUs, microprocessors (microprocessors), or other electronic components for performing the aforementioned methods.

In an exemplary embodiment, the present application further provides a computer readable storage medium, such as a memory 52, comprising a computer program, which is executable by a processor 51 of a communication device to perform the steps of the aforementioned method. The computer readable storage medium can be Memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash Memory, magnetic surface Memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.

The computer-readable storage medium provided in the embodiment of the present application stores thereon a computer program, and when the computer program is executed by a processor, the computer program implements the steps of the capability openness information obtaining method applied to the first device in the embodiment of the present application; or, the program, when executed by the processor, implements the steps of the capability openness information obtaining method applied in the second device in the embodiment of the present application; or, the program, when executed by the processor, implements the steps of the capability openness information obtaining method applied in the third device in the embodiment of the present application; or, the program, when executed by the processor, implements the steps of the capability openness information obtaining method applied to the fourth device in the embodiment of the present application.

The methods disclosed in the several method embodiments provided in the present application may be combined arbitrarily without conflict to obtain new method embodiments.

Features disclosed in several of the product embodiments provided in the present application may be combined in any combination to yield new product embodiments without conflict.

The features disclosed in the several method or apparatus embodiments provided in the present application may be combined arbitrarily, without conflict, to arrive at new method embodiments or apparatus embodiments.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above-described device embodiments are merely illustrative, for example, the division of the unit is only a logical functional division, and there may be other division ways in actual implementation, such as: multiple units or components may be combined, or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the coupling, direct coupling or communication connection between the components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between the devices or units may be electrical, mechanical or other forms.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on multiple network units; some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be separately regarded as one unit, or two or more units may be integrated into one unit; the integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.

Those of ordinary skill in the art will understand that: all or part of the steps for implementing the method embodiments may be implemented by hardware related to program instructions, and the program may be stored in a computer readable storage medium, and when executed, the program performs the steps including the method embodiments; and the aforementioned storage medium includes: a removable storage device, a ROM, a RAM, a magnetic or optical disk, or various other media capable of storing program code.

Alternatively, the integrated units described above in the present application may be stored in a computer-readable storage medium if they are implemented in the form of software functional modules and sold or used as independent products. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially implemented or portions thereof contributing to the prior art may be embodied in the form of a software product stored in a storage medium, and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a removable storage device, a ROM, a RAM, a magnetic or optical disk, or various other media that can store program code.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A capability openness information acquisition method, the method comprising:

2. The method of claim 1, further comprising:

the first device receives the capability information from the second device.

3. The method of claim 2, wherein the capability information comprises at least one of the following information: the device comprises a capability identifier, type information of the third device, a domain name of the third device, an Internet Protocol (IP) address of the third device and identity authentication information of the third device.

4. The method of claim 3, wherein the capability identification comprises at least one of: location service capability identification, wireless network information service capability identification, monitoring capability identification, pre-configuration capability identification and policy/charging capability identification.

5. The method of claim 4, wherein the wireless network information service capability identification comprises at least one of: the system comprises a wireless access network information identifier, a slicing capability identifier, an access user capability identifier, a multi-standard network access identifier and a data statistics report capability identifier.

6. The method of claim 3, wherein the type information of the third device comprises at least one of: a wireless access network identifier, a network function identifier of a core network, and a third-party system identifier.

7. The method according to any one of claims 1 to 6, further comprising:

and the first equipment receives second information from the second equipment, wherein the second information comprises capability acquisition fault repair information.

8. The method of claim 2, further comprising:

9. The method of claim 8, wherein the capability information supported by the first device comprises at least one of: the identifier of the first device, the type of the network that the first device supports accessing, an indication of whether the first device supports capability opening, an indication of whether the first device indicates internet security protocol IPSec, performance information of the first device, and an indication of whether the first device supports wide area interconnection.

10. The method of claim 9, wherein the capability information of the first device comprises at least one of: interface bandwidth of the first device, and a number of fourth devices supported by the first device.

11. The method of claim 8, wherein the authentication information of the fourth device comprises at least one of: the identity of the fourth device, the IP address of the fourth device, the domain name of the fourth device, and the identity authentication information of the fourth device.

12. The method according to any one of claims 2 to 11, further comprising:

and the first equipment sends the capability information to fourth equipment.

13. The method according to claim 12, wherein in the case that the slice capability information includes a slice capability identifier, the capability information further includes configuration information of slice parameter templates, the number of slice parameter templates, and the identifier of the slice parameter template.

14. The method of claim 13, wherein the configuration information of the slice parameter template includes slice parameters and their value ranges of at least one of the following:

the maximum number of users is supported by the slice;

slicing a service area;

slicing end-to-end delay;

the moving grade of the terminal in the slice;

slice resource sharing level;

slice reliability requirements.

15. The method according to claim 13 or 14, further comprising:

16. A capability openness information acquisition method, the method comprising:

17. The method of claim 16, wherein sending capability openness information to the first device comprises:

and the third equipment opens a capability application programming interface, and sends capability opening information to the first equipment based on the opened capability application programming interface.

18. The method of claim 17, further comprising:

transmitting a message between the third device and the first device;

19. The method of claim 16, further comprising:

the third equipment authenticates the first equipment through second equipment;

20. The method of claim 19, wherein the capability information comprises at least one of the following information: the device comprises a capability identifier, type information of the third device, a domain name of the third device, an Internet Protocol (IP) address of the third device and identity authentication information of the third device.

21. The method of claim 20, wherein the capability identification comprises at least one of: location service capability identification, wireless network information service capability identification, monitoring capability identification, pre-configuration capability identification and policy/charging capability identification.

22. The method of claim 21, wherein the wireless network information service capability identification comprises at least one of: the system comprises a wireless access network information identifier, a slicing capability identifier, an access user capability identifier, a multi-standard network access identifier and a data statistics report capability identifier.

23. The method of claim 21, wherein the type information of the third device comprises at least one of: a wireless access network identifier, a network function identifier of a core network, and a third-party system identifier.

24. A capability openness information acquisition method, the method comprising:

25. The method of claim 24, wherein the capability information comprises at least one of the following information: the device comprises a capability identifier, type information of the third device, a domain name of the third device, an Internet Protocol (IP) address of the third device and identity authentication information of the third device.

26. The method of claim 25, wherein the capability identifier comprises at least one of: location service capability identification, wireless network information service capability identification, monitoring capability identification, pre-configuration capability identification and policy/charging capability identification.

27. The method of claim 26, wherein the wireless network information service capability identification comprises at least one of: the system comprises a wireless access network information identifier, a slicing capability identifier, an access user capability identifier, a multi-standard network access identifier and a data statistics report capability identifier.

28. The method of claim 25, wherein the type information of the third device comprises at least one of: a wireless access network identification, a network function identification of a core network, and a third-party system identification.

29. The method of any one of claims 24 to 28, further comprising:

30. The method of claim 29, wherein the list of capability information supported by the first device comprises at least one of: the identifier of the first device, the type of the network that the first device supports accessing, an indication of whether the first device supports network capability opening, an indication of whether the first device indicates internet security protocol IPSec, performance information of the first device, and an indication of whether the first device supports wide area interconnection.

31. The method of claim 30, wherein the performance information of the first device comprises at least one of: interface bandwidth of the first device, and a number of fourth devices supported by the first device.

32. The method of claim 29, wherein the authentication information of the fourth device comprises at least one of: the identity of the fourth device, the IP address of the fourth device, the domain name of the fourth device, and the identity authentication information of the fourth device.

33. A capability openness information acquisition method, the method comprising:

34. The method of claim 33, wherein the fourth device receives capability information from the first device, comprising:

35. The method of claim 33, wherein the capability information comprises at least one of the following information: the capability identifier, the type information of the third device, the domain name of the third device, the Internet Protocol (IP) address of the third device, and the identity authentication information of the third device.

36. The method of claim 35, wherein the capability identification comprises at least one of: location service capability identification, wireless network information service capability identification, monitoring capability identification, pre-configuration capability identification and strategy/charging capability identification;

wherein the wireless network information service capability identification comprises at least one of: the system comprises a wireless access network information identifier, a slicing capability identifier, an access user capability identifier, a multi-standard network access identifier and a data statistics report capability identifier.

37. The method of claim 35, wherein the type information of the third device comprises at least one of: a wireless access network identifier, a network function identifier of a core network, and a third-party system identifier.

38. The method according to claim 36, wherein in case that the wireless network information service capability identifier includes an access user capability identifier, the fourth device performs processing of corresponding capability based on the capability information, including:

39. The method of claim 38, further comprising:

40. The method according to claim 36, wherein in case that the wireless network information service capability identifier includes a slice capability identifier, the capability information further includes configuration information of slice parameter templates, the number of slice parameter templates, and an identifier of a slice parameter template;

the maximum number of users is supported by the slice;

slicing a service area;

slicing end-to-end delay;

the moving grade of the terminal in the slice;

slice resource sharing level;

slicing reliability requirements.

41. The method of claim 40, wherein the fourth device performs processing of the corresponding capability based on the capability information, comprising:

the fourth device sends a first slice configuration request to the first device, wherein the first slice configuration request comprises indication information used for indicating a standard slice parameter template type or indication information used for indicating a self-defined slice parameter template type and a self-defined template parameter;

42. The method of any one of claims 33 to 41, further comprising:

the fourth device receives a broadcast message from the first device;

receiving a second access authentication response from the first device.

43. An open capability information acquisition apparatus, comprising: a first transmitting unit and a first receiving unit; wherein the content of the first and second substances,

44. An open capability information acquisition apparatus, comprising: the first receiving unit, the first processing unit and the first sending unit are connected; wherein, the first and the second end of the pipe are connected with each other,

the second receiving unit is used for receiving a first request from the first equipment; the first request is used for requesting capability opening; the first request comprises identity authentication information used for authentication;

45. An open capability information acquisition apparatus, comprising: a third receiving unit and a third transmitting unit; wherein the content of the first and second substances,

46. An open capability information acquisition apparatus, comprising: a fourth receiving unit and a fourth processing unit; wherein the content of the first and second substances,

47. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 15; alternatively, the first and second liquid crystal display panels may be,

the program when executed by a processor implementing the steps of the method of any one of claims 16 to 23; alternatively, the first and second liquid crystal display panels may be,

the program when executed by a processor implementing the steps of the method of any one of claims 24 to 32; alternatively, the first and second electrodes may be,

the program when executed by a processor implementing the steps of the method of any one of claims 33 to 42.

48. A communication device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the steps of the method of any one of claims 1 to 15 are implemented when the program is executed by the processor; alternatively, the first and second electrodes may be,

the processor, when executing the program, implementing the steps of the method of any one of claims 16 to 23; alternatively, the first and second electrodes may be,

the processor, when executing the program, performs the steps of the method of any one of claims 24 to 32; alternatively, the first and second electrodes may be,

the processor, when executing the program, performs the steps of the method of any of claims 33 to 42.