Networking architecture, access method, device and equipment

Abstract

The invention discloses a networking architecture, an access method, an access device and equipment. The networking architecture comprises a hospital, a core network and a medical conjunct management platform, a medical conjoined body is created on the medical conjoined body management platform; a virtual network VN group corresponding to the medical ad is created on the core network; wherein a medical edge cloud and a resident gateway RG are deployed on one side of the hospital, and a wired access gateway function W-AGF is deployed on one side of the core network; the RG is used for joining the VN group corresponding to the medical ad through the core network; and the medical edge cloud is used for accessing the core network through the RG and the W-AGF.

Description

Technical Field

[0001] This application relates to the fields of communication and computer technology, and in particular to a network architecture, access method, apparatus, and equipment. Background Technology

[0002] Telemedicine networks are typically built within medical consortia to provide telemedicine services to medical institutions within the consortium, promote resource sharing, and facilitate research and teaching. However, the current networking methods for telemedicine networks within medical consortia cannot guarantee the security of medical data and suffer from high costs and resource contention issues. Summary of the Invention

[0003] To address the aforementioned technical problems, embodiments of the present invention provide a network architecture, access method, apparatus, and device.

[0004] The networking architecture provided in this application embodiment includes: a hospital, a core network, and a medical consortium management platform; medical consortia are created on the medical consortium management platform; virtual network (VN) groups corresponding to the medical consortia are created on the core network; wherein...

[0005] The hospital side is equipped with a medical edge cloud and a resident gateway RG, while the core network side is equipped with a wired access gateway function W-AGF. The RG is used to join the VN group corresponding to the medical consortium through the core network. The medical edge cloud is used to access the core network through the RG and the W-AGF.

[0006] The access method provided in this application embodiment is applied to a first network function in the core network, including:

[0007] The first network function receives a third request sent by the second network function, the third request being used to request the first network function to perform identity authentication on the RG on the hospital side;

[0008] The first network function obtains the RG's signing information and performs identity authentication on the RG based on the RG's signing information.

[0009] The access method provided in this application embodiment is applied to a third network function in the core network, including:

[0010] The third network function receives a fourth request initiated by the RG on the hospital side, the fourth request being used to request the third network function to create a PDU session for the medical edge cloud;

[0011] The third network function triggers the establishment of a connection between the RG and the medical consortium AAA server. The connection is used by the RG to send a fifth request to the medical consortium AAA server. The fifth request is used to request the medical consortium AAA server to perform identity authentication for the medical edge cloud.

[0012] The third network function receives the identity authentication result sent by the medical consortium AAA server.

[0013] The access device provided in this application embodiment is applied to a first network function in the core network, including:

[0014] The first receiving unit is used to receive a third request sent by the second network function, wherein the third request is used to request the first network function to perform identity authentication on the RG on the hospital side.

[0015] The first verification unit is used to obtain the signing information of the RG through the first network function and to perform identity authentication on the RG based on the signing information of the RG.

[0016] The access device provided in this application embodiment is applied to a third network function in the core network, including:

[0017] The second receiving unit is used to receive a fourth request initiated by the RG on the hospital side of the third network function. The fourth request is used to request the third network function to create a PDU session for the medical edge cloud.

[0018] The second verification unit is used to trigger the establishment of a connection between the RG and the medical consortium AAA server, the connection being used by the RG to send a fifth request to the medical consortium AAA server, the fifth request being used to request the medical consortium AAA server to perform identity authentication for the medical edge cloud;

[0019] The second receiving unit is also used to receive the identity authentication result sent by the medical consortium AAA server via the third network function.

[0020] The communication device provided in this application includes a processor and a memory. The memory is used to store computer programs, and the processor is used to call and run the computer programs stored in the memory to execute any of the above-described access methods.

[0021] The computer-readable storage medium provided in this application embodiment is used to store a computer program that causes a computer to execute any of the above-described access methods.

[0022] The computer program product provided in this application includes computer program instructions that cause a computer to execute any of the above-described access methods.

[0023] The technical solution of this application provides a networking architecture, which includes: a hospital, a core network, and a medical consortium management platform; medical consortia are created on the medical consortium management platform; virtual network (VN) groups corresponding to the medical consortia are created on the core network; wherein, a medical edge cloud and a resident gateway (RG) are deployed on the hospital side, and a wired access gateway (W-AGF) is deployed on the core network side; the RG is used to join the VN group corresponding to the medical consortium through the core network; the medical edge cloud is used to access the core network through the RG and W-AGF. That is to say, the medical edge cloud can access the core network through a wired network, which can reduce the contention for wireless frequency band resources; at the same time, relying on the RG, the hospital's medical edge cloud can achieve UE-like functionality, that is, it can quickly connect to the core network like a UE, realizing the rapid construction of the hospital's telemedicine network and reducing the cost of using the hospital network; furthermore, the medical edge clouds of two hospitals can be directly connected through the core network without going through external networks and cloud platforms, which can significantly improve the network performance and data security of inter-hospital interconnection. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the architecture of the 5G fixed-mobile converged network provided in the embodiments of this application;

[0025] Figure 2 This is a schematic diagram of the 5G LAN user plane architecture provided in an embodiment of this application;

[0026] Figure 3 This is a schematic diagram of the 5G VN group configuration information update process provided in the embodiments of this application;

[0027] Figure 4 This is a schematic diagram illustrating the principle of data forwarding within a 5G LAN (5G VN group) provided in an embodiment of this application;

[0028] Figure 5 This is a schematic diagram of the system architecture of the 5G lightweight core network provided in the embodiments of this application;

[0029] Figure 6 This is a schematic diagram of the network structure of a medical consortium telemedicine private network based on a central cloud or public cloud, provided in an embodiment of this application.

[0030] Figure 7 This is a schematic diagram of the network structure of a medical consortium telemedicine private network based on "5G + edge cloud" provided in the embodiments of this application;

[0031] Figure 8 This is a schematic diagram of a network architecture provided in an embodiment of this application;

[0032] Figure 9This is a flowchart illustrating the access method one provided in this application embodiment;

[0033] Figure 10 This is a flowchart illustrating the second access method provided in this application embodiment;

[0034] Figure 11 This is a schematic diagram of the overall network architecture of the 5G remote medical private network provided in the embodiments of this application;

[0035] Figure 12 This is a schematic diagram illustrating the deployment and configuration process of the TCM consortium on the network architecture provided in this application embodiment;

[0036] Figure 13 This is a schematic diagram of the hospital-side deployment and configuration process in the network architecture provided in this application embodiment;

[0037] Figure 14 This is a schematic diagram of the process of 5G-RG accessing 5GC during the hospital's access to the medical consortium provided in the embodiments of this application;

[0038] Figure 15 This is a schematic diagram of the process of medical edge cloud accessing 5G-RG during the hospital access to the medical consortium provided in the embodiments of this application;

[0039] Figure 16 This is a schematic diagram of the structure of the access device provided in an embodiment of this application;

[0040] Figure 17 This is a schematic diagram of the structure of the access device two provided in the embodiments of this application;

[0041] Figure 18 This is a schematic diagram of the structure of the communication device provided in the embodiments of this application. Detailed Implementation

[0042] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0043] In the description of the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, in the embodiments of this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0044] In the description of the embodiments of this application, the term "correspondence" may indicate that there is a direct or indirect correspondence between two things, or that there is an association between two things, or that there is a relationship of instruction and being instructed, configuration and being configured, etc.

[0045] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and they all fall within the protection scope of the embodiments of this application.

[0046] (1) 5G fixed-mobile convergence

[0047] Fixed-mobile convergence, also known as wireless-wired convergence, achieves full-service and converged service operation through the integration and cooperation between fixed and mobile networks. To realize 5G fixed-mobile convergence, the 3GPP specification defines two types of gateways: Resential Gateway (RG) and Wireline Access Gateway Function (W-AGF), deployed on the user side and network side respectively, to address the convergence issues at these two locations. Specifically, these include:

[0048] 1) RG is located between the terminal and the access network, and is further divided into 5G-RG and Fixed Network RG (FN-RG). 5G-RG has 5G communication capabilities and can be connected to NG RAN as well as wired access networks; while FN-RG can only be connected to wired access networks.

[0049] 2) W-AGF is located between the wired access network and the 5G Core Network (5GC). Together with the wired access network, it forms the wired 5G access network (W-5GAN). It connects with 5GC through the standard 3GPP N2 and N3 interfaces.

[0050] Among them, "RG+W-AGF" is the foundation for realizing 5G fixed-mobile convergence, such as Figure 1 The diagram shows a fixed-mobile converged network architecture based on "RG+W-AGF". Figure 1 In this process, the terminal first accesses 5G-RG through a non-3GPP network (WLAN, wired, Bluetooth, etc.), and after 5G-RG protocol conversion, it accesses the 5G core network through a 5G mobile communication network or a wired communication network.

[0051] (2) 5G LAN technology

[0052] In offices, businesses, factories, and residences, 5G needs to provide functionality similar to local area networks (LANs) and virtual private networks (VPNs).

[0053] Among them, the three basic concepts related to 5G LAN are as follows:

[0054] 1) 5G LAN-type Service: Provides local area network communication services through 5G systems, which can use IP or non-IP communication types.

[0055] 2) 5G LAN Virtual Network (5G LAN-VN): A virtual network on a 5G system used to provide 5G LAN services.

[0056] 3) 5G VN Group: A group of UEs that use dedicated communication based on 5G LAN services.

[0057] Traditional 5G data channels are used for User Equipment (UE) to access the Data Network (DN), such as when a UE accesses the Internet or a private enterprise network. In contrast, 5G LAN-based data channels are used for UE-to-UE communication. Data packets initiated by the source UE are directly forwarded to the destination UE on the User Plane Function (UPF) within the 5G LAN, without needing to be routed through the DN. This significantly reduces network latency between UEs and improves network reliability. Figure 2 The diagram shows a 5G LAN user plane architecture. 5G LAN communication supports the following three types of traffic forwarding:

[0058] 1) Local switching: Traffic is forwarded locally by a single UPF, which is a common PSAUPF for different PDU sessions in the same 5G VN group.

[0059] 2) Based on the N19 interface: Uplink and downlink traffic for 5G VN communication is forwarded between PSAUPFs of different PDU sessions via N19. N19 is a shared user plane tunnel between interconnected PSA UPFs within the same 5G VN group.

[0060] 3) Based on N6 interface: 5G VN communication uplink and downlink traffic comes from or is sent to DN.

[0061] In the 3GPP standard, 5G VN groups can be configured by network administrators or dynamically managed by Application Functions (AFs). To support the dynamic management of 5G VN group identifiers and members, the Network Exposure Function (NEF) provides a set of services to manage (such as adding, deleting, and modifying) 5G VN groups and 5G VN members, and to dynamically manage 5G VN group data.

[0062] When the AF provides 5G VN group configuration, it triggers a general subscription data update and policy update process, saving the 5G VN group configuration information in the 5GC's Unified Data Management (UDM) or Unified Data Repository (UDR) function, and updating the UE's relevant configuration information. For example... Figure 3 The diagram shows the 5GVN group configuration information update process, which includes the following steps:

[0063] Step 301: The AMF associates with the Policy Control Function (PCF), and the PCF sends a subscription message for data modification notification to the UDR.

[0064] Step 302: AF creates AF request.

[0065] Step 303: AF sends a 5G VN group configuration update request message to NEF.

[0066] Step 304: NEF and UDR synchronize and store the updated 5G VN group configuration information.

[0067] Step 305: UDR sends a data modification notification message to PCF.

[0068] Step 306: The PCF triggers the UE to update its policy and sends the UE update policy to the AMF. The AMF sends the UE policy to the UE, thereby enabling the UE to update its UE policy.

[0069] To enable the "UE-to-UE data forwarding within the core network" function in 5G LAN, the 3GPP standard has made the following enhancements to the UE's PDU session procedure:

[0070] 1) The network operator sets up a (DNN, S-NSSAI) combination and maps it to the 5G VN group in a 1:1 ratio.

[0071] 2) When the UE creates a PDU session, it carries the specified (DNN, S-NSSAI) to indicate that this PDU session is a 5G VN group session.

[0072] 3) A UE’s PDU session provides access to one and only one 5G VN group.

[0073] 4) After receiving the PDU session request, the Session Management Function (SMF) selects a suitable UPF for the UE and configures the 5G VN group forwarding rules for the UE on it, so that communication between members in the 5G VN group is forwarded within the 5G core network. For the specific form and configuration method of the forwarding rules, please refer to 3GPP TS23.501.

[0074] The data forwarding principle of the 5G VN group after the above processing is as follows: Figure 4 As shown. Among them, Figure 4 Data packets sent from UE1 to UE2 are first sent to UPF1 through the PDU session PDU1 created by UE1. Then, UPF1 forwards the packets to the PDU session PDU2 created by UE2 based on the forwarding rules configured in SMF, and finally to UE2.

[0075] (3) 5G lightweight core network

[0076] like Figure 5 The diagram illustrates the lightweight 5GC core network system architecture. The service-oriented architecture design concept defined by 3GPP provides system architecture guarantees for lightweight core network deployment. Through service-oriented architecture, 5GC network element functions are broken down into several fine-grained, reusable network services. These decoupled network elements are connected via a unified message bus, enabling plug-and-play functionality. Network services can be deployed uniformly or in a distributed manner, providing agile system architecture support for lightweight 5GC. Based on service-oriented architecture, unnecessary network elements can be eliminated, creating lightweight core network products where network element function services can be combined on demand.

[0077] (4) Related technical shortcomings and technical problems to be solved

[0078] Currently, telemedicine networks are typically built upon medical consortia (or medical alliances) to provide telemedicine services to medical institutions within the consortium, promote resource sharing, and facilitate research and teaching collaboration. Specifically, the networking methods for telemedicine networks within medical consortia include the following two:

[0079] 1) Dedicated telemedicine network for medical consortia based on central cloud / public cloud. For example... Figure 6 The diagram shows the network structure of a medical consortium's telemedicine private network based on a central cloud or public cloud. The main body is a tertiary hospital, and the medical consortium's cloud data center and public cloud carry the core medical business system of the medical consortium. Branch hospitals usually use dedicated lines and Internet links to achieve interconnection and connection with the core business system on the cloud.

[0080] 2) Networking of a medical consortium's telemedicine network based on "5G + edge cloud". For example... Figure 7 The diagram shows the network structure of a medical consortium's telemedicine private network based on "5G + edge cloud". The 5G medical edge cloud is deployed inside or near the network edge of a tertiary hospital, carrying the core medical business system of the medical consortium. Branch hospitals usually use dedicated lines or 5G links to achieve interconnection with the 5G medical edge cloud.

[0081] However, the networking methods for establishing telemedicine networks within medical consortia in related technologies still have the following technical problems:

[0082] 1) Data security issues: Medical data contains a lot of sensitive and private information, so hospitals generally have the demand for "data not leaving the hospital area". However, under the networking method of related technologies, the data of each hospital will be sent to the cloud deployed outside the hospital, which poses a data security risk.

[0083] 2) High cost and difficult operation and maintenance of leased lines: Medical consortia connect tertiary hospitals, secondary hospitals, community hospitals and rural health centers by leasing leased lines from operators. As the number of branch medical outlets and telemedicine services increases, the number of leased line links also increases, and the cost of bandwidth expansion surges, resulting in high investment costs. In addition, leased lines generally need to be deployed separately, with long application and deployment cycles. At the same time, VPN configuration is complex and requires high technical skills from operation and maintenance personnel, leading to increased labor costs.

[0084] 3) 5G wireless frequency band resource contention: In addition to dedicated lines, medical institutions can access the medical consortium's telemedicine network through 5G networks. However, in this way, local 5G medical applications and telemedicine applications share 5G wireless frequency band resources, and resource contention will inevitably occur.

[0085] To address the aforementioned technical challenges, this application proposes a 5G remote medical private network architecture for building a medical consortium based on a 5G network. This architecture connects the medical edge cloud within the hospitals participating in the consortium to the 5GC network using a 5G fixed-mobile converged architecture. Direct interconnection between the medical edge clouds of different hospitals is achieved through 5G LAN functionality, eliminating the need to access external networks or platforms. This fulfills the hospital's requirement for data to remain within the hospital premises, significantly improving network performance and data security for inter-hospital interconnection. Furthermore, it enables second-level, UE-like access of the medical edge cloud to the medical consortium, supports wired and wireless dual-channel access, reduces competition for 5G wireless frequency band resources, and enhances network bandwidth and reliability.

[0086] To facilitate understanding of the technical solutions of the embodiments of this application, the technical solutions of this application are described in detail below through specific embodiments. The above-mentioned related technologies are optional solutions and can be arbitrarily combined with the technical solutions of the embodiments of this application, all of which fall within the protection scope of the embodiments of this application. The embodiments of this application include at least some of the following contents.

[0087] This application proposes a networking architecture. Figure 8 This is a schematic diagram of the network architecture provided in the embodiments of this application, such as... Figure 8 As shown, the network architecture includes the hospital 801, the core network 802, and the medical consortium management platform 803; medical consortia are created on the medical consortium management platform 803; and virtual network (VN) groups corresponding to the medical consortia are created on the core network 802.

[0088] Among them, the hospital 801 is equipped with a medical edge cloud and a resident gateway RG, and the core network 802 is equipped with a wired access gateway function W-AGF.

[0089] RG is used to join the corresponding VN group of the medical consortium through the core network;

[0090] Medical edge cloud is used to access the core network 802 via RG and W-AGF.

[0091] In this embodiment, hospital 801 is equipped with a medical edge cloud and RG, specifically 5G-RG; core network 802 is specifically 5GC, and is equipped with one or more W-AGF; medical consortium management platform 803 creates one or more medical consortia, and correspondingly, core network 802 creates one or more VN groups corresponding to the medical consortia; wherein, the RG deployed in hospital 801 can join the VN group corresponding to the medical consortium through the core network, and the medical edge cloud deployed in hospital 801 can access core network 802 through the RG deployed in hospital 801 and the W-AGF deployed in core network 802.

[0092] It should be noted that when deploying W-AGF on core network 802, the deployment should be based on the distribution of hospitals 801 to facilitate access to the medical consortium. For example, one W-AGF should be deployed near each tertiary hospital within the medical consortium for tertiary hospitals to access the consortium; and one W-AGF should be deployed in each administrative district within the city for lower-level hospitals such as secondary hospitals and community hospitals within that district to access the medical consortium.

[0093] Here, each medical consortium created by the medical consortium management platform 803 includes one or more of the following information: medical consortium identifier, medical consortium name, medical consortium type (tertiary hospital, secondary hospital, community hospital, etc.), and the corresponding VN group information of the medical consortium.

[0094] Here, since 5G-RG can join the VN group corresponding to the medical consortium through the core network 802, after 5G-RG successfully joins the VN group corresponding to the medical consortium, the VN group may include a group of 5G-RGs using dedicated communication based on LAN services.

[0095] Here, the core network 802 can be customized into a lightweight 5GC for medical consortia according to actual needs, and the core network 802 can support 5G fixed-mobile convergence and 5G LAN functions.

[0096] In some implementations, the medical consortium management platform 803 can be used to send a first request to the core network 802. The first request is used to request the core network 802 to create a VN group corresponding to the medical consortium based on the information carried in the first request. The information carried in the first request includes a VN group identifier and / or VN group configuration information. The VN group configuration information includes one or more of the following information corresponding to the LAN services provided by the VN group: DNN, slice identifier, PDU session type, and medical consortium AAA server address.

[0097] Here, the medical consortium management platform 803 can issue one or more 5G VN group creation requests corresponding to the medical consortium to the core network 802 through Operation Administration and Maintenance (OAM) or NEF. The request information includes, but is not limited to: 5G VN group identifier, 5G VN group configuration information, and the 5G VN group configuration information includes, but is not limited to: DNN, slice identifier, PDU session type, and medical consortium AAA server address information corresponding to the 5G LAN service provided by the 5G VN group.

[0098] In some implementations, the medical consortium management platform 803 contains the contract information of hospital 801 and / or RG; correspondingly, the core network 802 is used to store the contract information of hospital 801 and / or RG. Specifically, the contract information of hospital 801 and / or RG is written into the UDM of the core network via OAM. The contract information of hospital 801 includes one or more of the following: hospital identifier, hospital name, hospital type (tertiary hospital, secondary hospital, community hospital, etc.), medical consortium identifier, and hospital outbound network requirements. The contract information of RG includes one or more of the following: RG identifier, indication of RG's contract with the medical consortium, and wired line identifier for RG's access to W-AGF. The hospital outbound network requirements include one or more of the following: network bandwidth requirements, network latency requirements, and wired / wireless dual-channel requirements.

[0099] In some implementations, 5G-RG is also used to enable wireless network functionality based on the wired and wireless dual-channel requirements of the hospital's outbound network, and to provide telemedicine services through this wireless network functionality.

[0100] If the hospital 801 has a need to enable wired and wireless dual channels, then the 5G wireless function can be enabled for the 5G-RG of the hospital 801. At this time, it is necessary to ensure that the high-quality 5G wireless signal covers the location of the 5G-RG so that the 5G-RG can provide remote medical services through the 5G network.

[0101] In some implementations, a wired link is established between the RG and the W-AGF for the RG to communicate with the core network 802.

[0102] Here, after the hospital (801 or 5G-RG) signs a contract with the medical consortium on the medical consortium management platform (803), it can select a 5G-RG with matching bandwidth capacity according to the hospital's network needs, deploy it inside the hospital, and then open a wired link from the 5G-RG to the nearest W-AGF. That is, the 5G-RG accesses the W-AGF via a wired link, and writes the information of the 5G-RG's contracted medical consortium into the UDM of the core network (802) through OAM. This contract information includes, but is not limited to: the 5G-RG identifier, the indication of the 5G-RG's contracted medical consortium, and the identifier of the wired line for the 5G-RG's access to the W-AGF.

[0103] In some implementations, the medical consortium management platform 803 is used to send a second request to the core network 802. The second request requests the core network 802 to add the RG deployed in the hospital 801 to the VN group corresponding to the medical consortium based on the information carried in the second request. The information carried in the second request includes the VN group identifier and / or RG identifier corresponding to the medical consortium.

[0104] Here, the medical consortium management platform 803 can send a request to the core network 802 via OAM or NEF to add 5G-RG to the 5G VN group corresponding to the medical consortium. The request information includes, but is not limited to: the 5G VN group identifier and the 5G-RG identifier corresponding to the medical consortium.

[0105] The technical solution of this application provides a networking architecture, which includes: a hospital, a core network, and a medical consortium management platform; medical consortia are created on the medical consortium management platform; virtual network (VN) groups corresponding to the medical consortia are created on the core network; wherein, a medical edge cloud and a resident gateway (RG) are deployed on the hospital side, and a wired access gateway (W-AGF) is deployed on the core network side; the RG is used to join the VN group corresponding to the medical consortium through the core network; the medical edge cloud is used to access the core network through the RG and W-AGF. That is to say, the medical edge cloud can access the core network through a wired network, which can reduce the contention for wireless frequency band resources; at the same time, relying on the RG, the hospital's medical edge cloud can achieve UE-like functionality, that is, it can quickly connect to the core network like a UE, realizing the rapid construction of the hospital's telemedicine network and reducing the cost of using the hospital network; furthermore, the medical edge clouds of two hospitals can be directly connected through the core network without going through external networks and cloud platforms, which can significantly improve the network performance and data security of inter-hospital interconnection.

[0106] Based on the above embodiments, this application proposes an access method, which is applied to a first network function in the core network. Figure 9 This is a flowchart illustrating the access method one provided in this application embodiment, as shown below. Figure 9 As shown, the method includes the following steps:

[0107] Step 901: The first network function receives a third request sent by the second network function. The third request is used to request the first network function to authenticate the identity of the RG on the hospital side.

[0108] Step 902: The first network function obtains the RG's contract information and performs identity authentication on the RG based on the RG's contract information.

[0109] In this application embodiment, the first network function is specifically the Authentication Server Function (AUSF), the second network function is specifically the Access and Mobility Management Function (AMF), and RG is specifically 5G-RG. During the process of 5G-RG accessing the core network on the hospital side, the 5G-RG carries the 5G-RG identifier and sends a registration request to the W-AGF. Next, the W-AGF selects the AMF and sends a 5G-RG registration request to the AMF, carrying the 5G-RG identifier and the wired line identifier for 5G-RG access to the W-AGF. Then, the AMF, carrying the 5G-RG identifier and the wired line identifier for 5G-RG access to the W-AGF, sends a 5G-RG identity authentication request (the third request) to the AUSF, requesting the AUSF to authenticate the 5G-RG on the hospital side. After receiving the third request from the AMF, the AUSF obtains the 5G-RG's subscription information from the UDM and performs identity authentication for the 5G-RG based on this subscription information. After authenticating the 5G-RG, the AUSF sends the 5G-RG authentication result to the AMF.

[0110] Here, since the AMF sends the 5G-RG third request to the AUSF carrying the 5G-RG identifier and the wired line identifier for 5G-RG access to W-AGF, the information carried in the third request includes the 5G-RG identifier and the wired line identifier for 5G-RG access to W-AGF.

[0111] Here, since the 5G-RG on the hospital side is written into the UDM of the core network through OAM after signing the medical consortium agreement, AUSF can obtain the 5G-RG signing information from the UDM.

[0112] It should be noted that the process of 5G-RG accessing the core network is the process of 5G-RG registering with the core network through the wired access network (wired link) and W-AGF. During the 5G-RG identity authentication process, the core network needs to verify the binding relationship between the 5G-RG identifier and the wired line identifier to ensure that the 5G-RG is only used for medical alliance connections within the hospital.

[0113] In some implementations, authenticating the identity of an RG based on its contractual information may specifically include:

[0114] If the RG identifier in the RG's subscription information is consistent with the RG identifier carried in the third request, and the wired line identifier in the RG's subscription information is consistent with the wired line identifier of RG accessing W-AGF carried in the third request, then the identity authentication of RG is confirmed to be successful.

[0115] If the RG identifier in the RG's contract information is inconsistent with the RG identifier carried in the third request, or if the wired line identifier in the RG's contract information is inconsistent with the wired line identifier for RG accessing W-AGF carried in the third request, then the RG's identity authentication is deemed to have failed.

[0116] Here, during the AUSF authentication process for 5G-RG, the following two conditions must be met simultaneously. If both conditions are met, the 5G-RG authentication will succeed; otherwise, authentication will fail. The specific conditions are as follows:

[0117] (1) 5G-RG has signed a medical consortium agreement.

[0118] (2) The wired line identifier in the 5G-RG contract information is consistent with the wired line identifier of 5G-RG access to W-AGF carried in the third request sent by AMF.

[0119] Specifically, if the 5G-RG identifier in the 5G-RG's contract information matches the 5G-RG identifier carried in the third request, it proves that 5G-RG has signed a contract with a medical consortium, and the wired line identifier in the 5G-RG's contract information matches the wired line identifier for 5G-RG accessing W-AGF carried in the third request, then the identity authentication of 5G-RG is determined to be successful; otherwise, if the 5G-RG identifier in the 5G-RG's contract information does not match the 5G-RG identifier carried in the third request, or if the wired line identifier in the 5G-RG's contract information does not match the wired line identifier for 5G-RG accessing W-AGF carried in the third request, then the identity authentication of 5G-RG is determined to be unsuccessful.

[0120] Here, after AUSF authenticates the 5G-RG, AUSF sends the authentication result of the 5G-RG to AMF. If the authentication is successful, AMF continues the subsequent 5G-RG registration process; if the authentication fails, AMF sends a registration failure message to the 5G-RG through W-AGF, rejecting the 5G-RG's registration request.

[0121] It should be noted that the above access method one is a sub-process one in the hospital access to the medical consortium process, namely the process of the hospital's 5G-RG access to the core network. The process of 5G-RG access to the core network is the process of 5G-RG registering to the core network through the wired access network (wired link) and W-AGF.

[0122] It should be noted that sub-process one in access method one and sub-process two in access method two below together constitute the process of hospital access to medical consortium, thereby forming an end-to-end network channel from the hospital's medical edge cloud to the medical consortium with 5G-RG as the internal and external network gateway.

[0123] Based on the above embodiments, this application proposes another access method, which is applied to a third network function in the core network. Figure 10 This is a flowchart illustrating the second access method provided in this application embodiment, as follows: Figure 10 As shown, the method includes the following steps:

[0124] Step 1001: The third network function receives a fourth request initiated by the RG on the hospital side. The fourth request is used to request the third network function to create a PDU session for the medical edge cloud.

[0125] Step 1002: The third network function triggers the establishment of a connection between RG and the medical consortium AAA server. The connection is used by RG to send a fifth request to the medical consortium AAA server. The fifth request is used to request the medical consortium AAA server to authenticate the identity of the medical edge cloud.

[0126] Step 1003: The third network function receives the identity authentication result sent by the medical consortium AAA server.

[0127] In this embodiment, the third network function is specifically SMF, and RG is specifically 5G-RG. During the process of the medical edge cloud accessing 5G-RG, the medical edge cloud can connect to 5G-RG via non-cellular network methods such as wireless LAN or wired links, and send an access request to 5G-RG carrying the medical consortium identifier, edge cloud device identifier, and edge cloud identity credential information. After receiving the access request from the medical edge cloud, 5G-RG carries the configuration information corresponding to the 5G VN group of the specified medical consortium and sends a request to SMF to create a PDU session, i.e., the fourth request, for requesting the creation of a PDU session providing 5G LAN services. After receiving the fourth request from 5G-RG, SMF, based on 5G... The configuration of the VN group TCM consortium AAA server address triggers the establishment of a connection between 5G-RG and the TCM consortium AAA server; then 5G-RG carries the edge cloud device identifier and edge cloud identity credential information, and sends an identity authentication request for the medical edge cloud to the TCM consortium AAA server, i.e., the fifth request, requesting the TCM consortium AAA server to authenticate the medical edge cloud; after the TCM consortium AAA server authenticates the medical edge cloud, the TCM consortium AAA server sends the identity authentication result of the medical edge cloud to SMF.

[0128] Here, the connection between 5G-RG and the medical consortium's AAA server is an Extensible Authentication Protocol (EAP) connection. An EAP connection is a network connection method that uses EAP to authenticate network access. EAP is a security protocol for network authentication that allows users to authenticate when connecting to wireless or wired networks to ensure secure data transmission.

[0129] Here, since 5G-RG carries the configuration information corresponding to the 5G VN group of the specified medical consortium, and is sent as the fourth request from the medical edge cloud to the SMF, the information carried in the fourth request includes the configuration information corresponding to the 5G VN group of the specified medical consortium, and the configuration information includes one or more of the following information corresponding to the 5G LAN service provided by the 5G VN group: DNN, slice identifier, PDU session type, and medical consortium AAA server address.

[0130] In some implementations, the establishment of a connection between the RG and the medical consortium AAA server triggered by the third network function may specifically include:

[0131] The third network function triggers the establishment of a connection between RG and the medical consortium AAA server based on the address of the medical consortium AAA server. The communication between RG and the medical consortium AAA server is forwarded through the third network function.

[0132] Here, after the SMF receives the fourth request sent by the 5G-RG, the SMF can trigger the establishment of an EAP connection between the 5G-RG and the medical consortium AAA server based on the address of the medical consortium AAA server carried in the fourth request. After the 5G-RG and the medical consortium AAA server establish an EAP connection, messages between the 5G-RG and the medical consortium AAA server need to be forwarded through the SMF.

[0133] Here, since 5G-RG sends the fifth request to the medical consortium AAA server carrying the edge cloud device identifier and edge cloud identity credential information, the information carried in the fifth request includes the edge cloud device identifier and edge cloud identity credential information, and the edge cloud identity credential information includes one or more of the following: username, password, and token.

[0134] Here, after the medical consortium AAA server receives the fifth request sent by 5G-RG, the medical consortium AAA server compares the edge cloud identity credential information with the information stored in the local database based on the information carried in the fifth request to verify whether the identity of the medical edge cloud is valid.

[0135] It should be noted that during the process of medical edge cloud accessing 5G-RG, the purpose of the medical consortium AAA server authenticating the identity of the medical edge cloud is to prevent unauthorized and illegal devices from accessing the network.

[0136] Here, after the medical consortium AAA server authenticates the identity of the medical edge cloud, the medical consortium AAA server sends the identity authentication result of the medical edge cloud to the SMF. If the identity authentication is successful, the SMF continues the subsequent PDU session creation process; if the identity authentication fails, the SMF sends a medical edge cloud identity authentication failure message to the 5G-RG, triggering the 5G-RG to reject the access request of the medical edge cloud.

[0137] It should be noted that the above-mentioned access method two is sub-process two in the hospital access to the medical consortium process, namely the process of medical edge cloud accessing 5G-RG. The medical edge cloud accesses 5G-RG through non-cellular network methods such as wireless local area network and wired link. Then, 5G-RG creates a PDU session to provide 5G LAN service for the medical edge cloud, enabling the medical edge cloud to access the core network, thereby enabling the medical edge cloud to access the medical consortium.

[0138] It should be noted that sub-process one in access method one and sub-process two in access method two together constitute the process of the hospital accessing the medical consortium, thereby forming an end-to-end network channel from the hospital's medical edge cloud to the medical consortium with 5G-RG as the internal and external network gateway.

[0139] The following is an explanation of the relevant identifiers appearing in the above embodiments:

[0140] (1) Medical consortium identification: used to uniquely identify the identity of a medical consortium within a designated area (such as a city, province, or country).

[0141] (2) Hospital Identifier: Used to uniquely identify the hospital within a designated area; 5G-RG Identifier is used to uniquely identify the 5G-RG within the medical consortium system.

[0142] (3) Wired line identification: used to uniquely identify the wired line for 5G-RG access to W-AGF within the medical consortium system.

[0143] (4) Edge cloud device identifier: used to uniquely identify the identity of the medical edge cloud within the medical consortium system.

[0144] This application also proposes a networking architecture for a 5G remote medical private network, such as... Figure 11 The diagram shown is a schematic representation of the overall network architecture of the 5G remote medical private network provided in this application embodiment. The specific configuration of this network architecture is as follows:

[0145] (1) Deployment and configuration on the medical consortium side. Deploy 5G fixed-mobile convergence and 5G LAN functions on the 5GC that carries the medical consortium services; deploy one or more W-AGFs according to the geographical distribution of hospitals; configure 5G VN groups for the medical consortium.

[0146] (2) Hospital-side deployment and configuration. Deploy 5G-RG in hospitals that have joined the medical consortium and access W-AGF via wired network; optionally enable 5G function of 5G-RG to enable 5G-RG to access via wired and wireless dual channels; add the 5G-RG deployed in the hospital to the corresponding 5G VN group of the medical consortium.

[0147] (3) Hospital access to 5G telemedicine private network. The hospital’s local medical edge cloud can access the locally deployed 5G-RG to realize the hospital’s access to the medical alliance. During the access process, 5G-RG and medical edge cloud need to be securely authenticated to ensure that 5G-RG is only used by the medical alliance’s telemedicine private network and that the medical edge cloud has a legitimate identity.

[0148] Specifically, such as Figure 12 The diagram shown illustrates the deployment and configuration process of the TCM consortium on the network architecture provided in this embodiment of the application. The process specifically includes the following steps:

[0149] Step 1201: Deploy the 5GC and medical consortium management platform.

[0150] Here, the deployment rules for 5GC, which carries the medical consortium business, and the medical consortium management platform are as follows:

[0151] (1) Deploy a lightweight 5GC specifically for the medical consortium according to actual needs. The network elements that must be selected and deployed locally in the lightweight 5GC include: AMF, SMF, and UPF. The network elements that must be selected but can be shared with the main network 5GC include: UDM and AUSF. The network elements that can be deployed optionally according to the medical consortium's operation strategy include: PCF, NEF, and Network Slice Selection Function (NSSF). Among them, if the 5GC requires flexible policy rule configuration, PCF needs to be deployed locally. If the medical consortium needs to use the 5GC's network open capabilities to obtain network data or distribute network configurations, NEF needs to be deployed locally. If the medical consortium needs the 5GC to support network slicing functions, NSSF needs to be deployed locally.

[0152] (2) The 5GC that carries the medical consortium business should support 5G LAN function and 5G fixed-mobile convergence function.

[0153] (3) One or more W-AGFs should be deployed as appropriate based on the distribution of hospitals to facilitate their access to the medical consortium. For example, one W-AGF should be deployed near each tertiary hospital in the medical consortium for that tertiary hospital to access the medical consortium; and one W-AGF should be deployed in each administrative district of the city for lower-level hospitals such as secondary hospitals and community hospitals in that district to access the medical consortium.

[0154] (4) The medical consortium management platform can connect to the OAM or NEF of the medical consortium 5GC via the Internet, dedicated line, etc., and send relevant configuration information to the 5GC. The configuration information includes, but is not limited to: configuration information for creating the 5G VN group corresponding to the medical consortium, and configuration information for adding the hospital's 5G-RG to the 5G VN group corresponding to the medical consortium.

[0155] Step 1202: Create a medical consortium on the medical consortium management platform.

[0156] Here, one or more medical alliances are created on the medical alliance management platform. The information of each medical alliance includes, but is not limited to: medical alliance identifier, medical alliance name, medical alliance type, and the 5G VN group information corresponding to the medical alliance.

[0157] Step 1203: Create the corresponding 5G VN group for the medical consortium on 5GC.

[0158] Here, the medical consortium management platform sends one or more 5G VN group creation requests corresponding to the medical consortium to the 5GC through OAM or NEF. The information carried in the request includes, but is not limited to: 5G VN group identifier and 5G VN group configuration information. The 5G VN group configuration information includes, but is not limited to: DNN, slice identifier, PDU session type, and medical consortium AAA server address information corresponding to the 5G LAN service provided by the 5G VN group.

[0159] like Figure 13 The diagram shown illustrates the hospital-side deployment and configuration process in the network architecture provided in this embodiment. The process specifically includes the following steps:

[0160] Step 1301: The hospital signs a medical consortium agreement.

[0161] Here, the hospital signs a medical consortium agreement on the medical consortium management platform. The hospital's agreement information includes, but is not limited to: hospital logo, hospital name, hospital type (such as tertiary hospital, secondary hospital, community hospital, village hospital), medical consortium logo, and hospital outbound network requirements. Among them, the hospital outbound network requirements include, but are not limited to: network bandwidth requirements, network latency requirements, and wired and wireless dual-channel requirements.

[0162] Step 1302: Deploy 5G-RG in the hospital.

[0163] Here, based on the hospital's network requirements, a 5G-RG with matching bandwidth capacity is selected and deployed inside the hospital. A wired link from the 5G-RG to the nearest W-AGF is established, and the information of the 5G-RG contracted medical consortium is written into the 5GC's UDM via OAM. The 5G-RG contract information includes, but is not limited to: the 5G-RG identifier, the indication of the 5G-RG contracted medical consortium, and the identifier of the wired line for 5G-RG access to W-AGF.

[0164] Step 1303: Activate 5G functionality for the hospital's 5G-RG.

[0165] If the hospital needs to enable wired and wireless dual channels, then the 5G wireless function should be enabled for the hospital's 5G-RG. At this time, it is necessary to ensure that high-quality 5G wireless signal coverage is provided at the location of the 5G-RG so that the 5G-RG can provide remote medical services through the 5G network.

[0166] Step 1304: Add the hospital's 5G-RG to the corresponding 5G VN group of the medical consortium.

[0167] Here, the medical consortium management platform sends a request to 5GC via OAM or NEF to add 5G-RG to the 5G VN group corresponding to the medical consortium. The information carried in the request includes, but is not limited to, the 5G VN group identifier and the 5G-RG identifier corresponding to the medical consortium.

[0168] After deployment and configuration are completed on both the medical consortium side and the hospital side, the hospital's medical edge cloud can be connected to the medical consortium. The process of the hospital connecting to the medical consortium includes two sub-processes: first, the hospital's 5G-RG connects to 5GC via wired connection; second, the medical edge cloud within the hospital connects to 5G-RG.

[0169] Sub-process 1: 5G-RG accesses 5GC via wired connection

[0170] The process of 5G-RG accessing 5GC is the process of 5G-RG registering with 5GC through the wired access network and W-AGF, such as... Figure 14 The diagram shown is a schematic representation of the process of 5G-RG accessing 5GC during the hospital's access to the medical consortium according to an embodiment of this application. The process specifically includes the following steps:

[0171] Step 1401: 5G-RG sends a registration request to W-AGF, carrying the 5G-RG identifier.

[0172] Step 1402: W-AGF selects AMF and sends a 5G-RG registration request to AMF, carrying the 5G-RG identifier and the wired line identifier for 5G-RG access to W-AGF.

[0173] Step 1403: The AMF sends a 5G-RG identity authentication request to the AUSF, carrying the 5G-RG identifier and the wired line identifier for 5G-RG access to W-AGF.

[0174] Step 1404: AUSF obtains the 5G-RG contract information from UDM.

[0175] Step 1405: AUSF authenticates the 5G-RG. If both of the following conditions are met, the 5G-RG authentication is successful; otherwise, authentication fails:

[0176] (1) 5G-RG has signed contracts with medical consortia;

[0177] (2) The wired line identifier in the 5G-RG subscription information is consistent with the wired line identifier of 5G-RG access to W-AGF carried in the 5G-RG identity authentication request sent by AMF.

[0178] Step 1406: AUSF sends the 5G-RG identity authentication result to AMF. If the authentication is successful, AMF continues the subsequent 5G-RG registration process; otherwise, it sends a registration failure message to 5G-RG through W-AGF and rejects the 5G-RG registration request.

[0179] Sub-process 2: Medical edge cloud access to 5G-RG

[0180] The hospital's medical edge cloud accesses 5G-RG via non-cellular networks such as WLAN and wired connections. Then, 5G-RG creates a PDU session providing 5G LAN services for the medical edge cloud, enabling it to access 5GC and thus connect to the medical consortium. For example... Figure 15 The diagram shown is a schematic representation of the process of medical edge cloud accessing 5G-RG during the hospital's access to the medical consortium, as provided in an embodiment of this application. The process specifically includes the following steps:

[0181] Step 1501: The medical edge cloud connects to 5G-RG and sends a request to access the medical consortium, carrying information including: medical consortium identifier, edge cloud device identifier, and edge cloud identity credential information (such as username, password, and digital certificate).

[0182] Step 1502: 5G-RG initiates a request to create a PDU session for the medical edge cloud, carrying the configuration information corresponding to the 5G VN group of the specified medical consortium, including but not limited to: PDU session type, DNN, and slice identifier.

[0183] Step 1503: Based on the configuration of the medical consortium AAA server address in the 5G VN group, the SMF triggers the establishment of an EAP connection between the 5G-RG and the medical consortium AAA server. Messages between the 5G-RG and the medical consortium AAA server need to be forwarded through the SMF.

[0184] Step 1504: The 5G-RG initiates an identity authentication request for the medical edge cloud to the medical consortium AAA server, carrying information including: edge cloud device identifier and edge cloud identity credential information, which includes, but is not limited to: username, password, and token. The medical consortium AAA server compares the edge cloud identity credential information with the information stored in its local database to verify the validity of the edge cloud's identity. After the medical consortium AAA server authenticates the medical edge cloud, it sends the authentication result to the SMF.

[0185] Step 1505: If the medical edge cloud identity authentication is successful, the SMF continues the subsequent PDU session creation process; otherwise, the SMF sends a medical edge cloud identity authentication failure message to the 5G-RG, triggering the 5G-RG to reject the medical edge cloud access request.

[0186] The technical advantages of the technical solution in this application are reflected in the following three aspects:

[0187] (1) Relying on 5G fixed-mobile convergence technology, 5G medical edge cloud can access 5GC through wired network, which can reduce the competition for 5G wireless frequency band resources. In addition, 5G medical edge cloud also supports wired and wireless dual-channel access, which can improve network bandwidth and reliability.

[0188] (2) Relying on 5G-RG, the hospital's 5G medical edge cloud can be UE-like, that is, it can connect to the 5G network in seconds like a 5G UE, enabling the rapid construction of the hospital's remote medical network; in addition, the hospital's 5G medical edge cloud can flexibly establish and disconnect network connections as needed, just like a 5G UE, and supports billing by traffic or access time, which can reduce the hospital's network usage costs.

[0189] (3) Relying on 5G LAN technology, the medical edge clouds of the two hospitals can be directly connected through 5GC without having to go through external networks and cloud platforms, which can greatly improve the network performance and data security of inter-hospital interconnection.

[0190] This application also proposes an access device, which is applied to a first network function in the core network. Figure 16 This is a schematic diagram of the structure of the access device one provided in the embodiment of this application, as shown below. Figure 16 As shown, the device includes:

[0191] The first receiving unit 1601 is used to receive a third request sent by the second network function. The third request is used to request the first network function to authenticate the identity of the RG on the hospital side.

[0192] The first verification unit 1602 is used to obtain the RG's contract information through the first network function and to authenticate the RG's identity based on the RG's contract information.

[0193] In some implementations, the third request carries the RG identifier and the wired line identifier for RG accessing W-AGF; correspondingly, the first verification unit 1602 is specifically configured to determine that the identity authentication of RG is successful if the RG identifier in the RG's subscription information is consistent with the RG identifier carried in the third request, and the wired line identifier in the RG's subscription information is consistent with the wired line identifier for RG accessing W-AGF carried in the third request; if the RG identifier in the RG's subscription information is inconsistent with the RG identifier carried in the third request, or the wired line identifier in the RG's subscription information is inconsistent with the wired line identifier for RG accessing W-AGF carried in the third request, then the identity authentication of RG is determined to fail.

[0194] This application also proposes another access device, which is applied to a third network function in the core network. Figure 17 This is a schematic diagram of the structure of the access device two provided in the embodiments of this application, as shown below. Figure 17 As shown, the device includes:

[0195] The second receiving unit 1701 is used to receive the fourth request initiated by the RG on the hospital side of the third network function. The fourth request is used to request the third network function to create a PDU session for the medical edge cloud.

[0196] The second verification unit 1702 is used to trigger the third network function to establish a connection between RG and the medical consortium AAA server. The connection is used by RG to send a fifth request to the medical consortium AAA server. The fifth request is used to request the medical consortium AAA server to perform identity authentication for the medical edge cloud.

[0197] The second receiving unit 1701 is also used for the third network function to receive the identity authentication result sent by the medical consortium AAA server.

[0198] In some implementations, the fourth request carries the VN group configuration information corresponding to the specified medical consortium. The VN group configuration information includes one or more of the following information corresponding to the LAN service provided by the VN group: DNN, slice identifier, PDU session type, and medical consortium AAA server address. Correspondingly, the second verification unit 1702 is specifically used for the third network function to trigger the establishment of a connection between RG and the medical consortium AAA server based on the medical consortium AAA server address, wherein the communication between RG and the medical consortium AAA server is forwarded through the third network function.

[0199] In some implementations, the fifth request carries an edge cloud device identifier and / or edge cloud identity credential information, which includes one or more of the following: username, user password, and token; wherein, the edge cloud identity credential information carried in the fifth request is used by the medical consortium AAA server to compare it with the information stored in the local database to verify whether the identity of the medical edge cloud is valid.

[0200] Those skilled in the art should understand that Figure 16 , 17 The functions of each unit in the access device shown can be understood by referring to the relevant description of the aforementioned method. Figure 16 , 17 The functions of each unit in the access device shown can be implemented by a program running on a processor or by specific logic circuits.

[0201] Figure 18 This is a schematic diagram of the structure of the communication device provided in an embodiment of this application. The communication device may be a terminal device or a network device. Figure 18 The communication device shown includes a processor 1801, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0202] Optionally, such as Figure 18 As shown, the communication device may further include a memory 1802. The processor 1801 can retrieve and run computer programs from the memory 1802 to implement the methods described in this embodiment.

[0203] The memory 1802 can be a separate device independent of the processor 1801, or it can be integrated into the processor 1801.

[0204] Optionally, such as Figure 18 As shown, the communication device may also include a transceiver 1803, and the processor 1801 can control the transceiver 1803 to communicate with other devices. Specifically, it can send information or data to other devices or receive information or data sent by other devices.

[0205] The transceiver 1803 may include a transmitter and a receiver. The transceiver 1803 may further include an antenna, and the number of antennas may be at least one.

[0206] The communication device may specifically be the access device in the embodiments of this application, and the communication device can implement the corresponding processes implemented by the access device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0207] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0208] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0209] It should be understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0210] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to the communication device in this application embodiment, and the computer program causes the computer to execute the corresponding processes implemented by the access device in the various methods of this application embodiment; for brevity, these will not be elaborated further here.

[0211] This application also provides a computer program product, including computer program instructions. This computer program product can be applied to the communication device in this application embodiment, and the computer program instructions cause the computer to execute the corresponding processes implemented by the access device in the various methods of this application embodiment; for simplicity, further details are omitted here.

[0212] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0213] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0214] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0215] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0216] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0217] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0218] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A network architecture, characterized in that, The network architecture includes: a hospital, a core network, and a medical consortium management platform; medical consortia are created on the medical consortium management platform; virtual network (VN) groups corresponding to the medical consortia are created on the core network; wherein... The hospital side is equipped with a medical edge cloud and a resident gateway RG, while the core network side is equipped with a wired access gateway function W-AGF. The RG is used to join the VN group corresponding to the medical consortium through the core network. The medical edge cloud is used to access the core network through the RG and the W-AGF.

2. The networking architecture according to claim 1, characterized in that, The medical consortium management platform is used to send a first request to the core network. The first request carries a VN group identifier and / or VN group configuration information. The VN group configuration information includes one or more of the following information corresponding to the LAN services provided by the VN group: DNN, slice identifier, PDU session type, and medical consortium AAA server address. The first request is used to request the core network to create a VN group corresponding to the medical consortium based on the information carried in the first request.

3. The networking architecture according to claim 1, characterized in that, The medical consortium management platform is used to send a second request to the core network, the second request carrying a VN group identifier and / or an RG identifier; wherein, the second request is used to request the core network to add the RG to the VN group corresponding to the medical consortium based on the information carried in the second request.

4. The networking architecture according to claim 1, characterized in that, The medical consortium management platform contains the contract information of the hospital and / or the contract information of the RG; The core network is used to store the hospital's contract information and / or the RG's contract information.

5. The networking architecture according to claim 4, characterized in that, The hospital's contract information includes one or more of the following: hospital identifier, hospital name, hospital type, medical consortium identifier, and hospital outbound network requirements. The RG's contract information includes one or more pieces of information: RG identifier, indication of the RG contracted medical consortium, and wired line identifier for RG access to W-AGF.

6. The networking architecture according to claim 5, characterized in that, The RG is also used to enable wireless network functionality based on the wired and wireless dual-channel requirements of the hospital's outbound network, and to provide remote medical services through the wireless network functionality.

7. The networking architecture according to any one of claims 1 to 6, characterized in that, A wired link is established between the RG and the W-AGF, and the wired link is used for the RG to communicate with the core network.

8. An access method, characterized in that, The method, which applies a first network function in the core network, includes: The first network function receives a third request sent by the second network function, the third request being used to request the first network function to perform identity authentication on the RG on the hospital side; The first network function obtains the RG's signing information and performs identity authentication on the RG based on the RG's signing information.

9. The method according to claim 8, characterized in that, The third request carries the RG identifier and the wired line identifier for RG access to W-AGF; The authentication of the RG based on the RG's signing information includes: If the RG identifier in the RG's subscription information is consistent with the RG identifier carried in the third request, and the wired line identifier in the RG's subscription information is consistent with the wired line identifier of the RG accessing W-AGF carried in the third request, then the identity authentication of the RG is determined to be successful. If the RG identifier in the RG's subscription information is inconsistent with the RG identifier carried in the third request, or if the wired line identifier in the RG's subscription information is inconsistent with the wired line identifier for RG accessing W-AGF carried in the third request, then the RG's identity authentication is determined to have failed.

10. An access method, characterized in that, The method, applied to a third network function in the core network, includes: The third network function receives a fourth request initiated by the RG on the hospital side, the fourth request being used to request the third network function to create a PDU session for the medical edge cloud; The third network function triggers the establishment of a connection between the RG and the medical consortium AAA server. The connection is used by the RG to send a fifth request to the medical consortium AAA server. The fifth request is used to request the medical consortium AAA server to perform identity authentication for the medical edge cloud. The third network function receives the identity authentication result sent by the medical consortium AAA server.

11. The method according to claim 10, characterized in that, The fourth request carries the VN group configuration information corresponding to the specified medical consortium. The VN group configuration information includes one or more of the following information corresponding to the LAN service provided by the VN group: DNN, slice identifier, PDU session type, and medical consortium AAA server address. The third network function triggers the establishment of a connection between the RG and the medical consortium AAA server, including: The third network function triggers the establishment of a connection between the RG and the medical consortium AAA server based on the address of the medical consortium AAA server, wherein the communication between the RG and the medical consortium AAA server is forwarded through the third network function.

12. The method according to claim 10, characterized in that, The fifth request carries an edge cloud device identifier and / or edge cloud identity credential information, wherein the edge cloud identity credential information includes one or more of the following: username, user password, and token; The edge cloud identity credential information carried in the fifth request is used by the medical consortium AAA server to compare it with the information stored in the local database to verify whether the identity of the medical edge cloud is valid.

13. An access device, characterized in that, The apparatus for a first network function applied in the core network includes: The first receiving unit is used to receive a third request sent by the second network function, wherein the third request is used to request the first network function to perform identity authentication on the RG on the hospital side. The first verification unit is used to obtain the signing information of the RG through the first network function and to perform identity authentication on the RG based on the signing information of the RG.

14. An access device, characterized in that, The apparatus, which is used for a third network function in the core network, includes: The second receiving unit is used to receive a fourth request initiated by the RG on the hospital side of the third network function. The fourth request is used to request the third network function to create a PDU session for the medical edge cloud. The second verification unit is used to trigger the establishment of a connection between the RG and the medical consortium AAA server, the connection being used by the RG to send a fifth request to the medical consortium AAA server, the fifth request being used to request the medical consortium AAA server to perform identity authentication for the medical edge cloud; The second receiving unit is also used to receive the identity authentication result sent by the medical consortium AAA server via the third network function.

15. A communication device, characterized in that, include: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to perform the method as described in any one of claims 8 to 12.

16. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the method as described in any one of claims 8 to 12.

17. A computer program product, characterized in that, It includes computer program instructions that cause a computer to perform the method as described in any one of claims 8 to 12.

Images