CN111699658B

CN111699658B - Apparatus and method for fronthaul network authentication in cloud radio access networks

Info

Publication number: CN111699658B
Application number: CN201780098239.9A
Authority: CN
Inventors: 杨佳平; 刘宏俊; 王子敬
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Priority date: 2017-12-29
Filing date: 2017-12-29
Publication date: 2023-01-10
Anticipated expiration: 2037-12-29
Also published as: CN111699658A; WO2019127482A1

Abstract

Embodiments of the present disclosure relate to methods, apparatuses, and devices for fronthaul network authentication in a cloud Radio Access Network (RAN). In an example embodiment, at an application running on a cloud server in a RAN, a first message for a type of traffic is generated based on a traffic profile. The service profile is predefined for the RAN and associated with that type of service. The first message indicates a message format for a second message to be received from a RAP in the RAN. The first message is caused to be transmitted to the RAP. Furthermore, transmission characteristics of the type of traffic in the RAN are determined based on detection of the second message from the RAP. In this way, the fronthaul network between the cloud server and the RAP can be validated efficiently and effectively.

Description

Apparatus and method for fronthaul network authentication in cloud radio access networks

Technical Field

Embodiments of the present disclosure generally relate to the field of communications, and in particular, to methods, apparatuses, and devices for fronthaul network authentication in cloud Radio Access Networks (RANs).

Background

A cloud RAN is a cloud-based access network architecture in a cellular network. In the cloud RAN, network device functions are implemented in a cloud server and Radio Access Points (RAPs) (also referred to as baseband units). Cloud servers are typically located in data centers, and RAPs can be deployed over distances of several kilometers. Network transmissions between the cloud server and the RAP may involve many different types of routing devices, such as switches, routers, etc. These routing devices form a fronthaul network between the cloud server and the RAP.

Transmission limitations in the fronthaul network may become a bottleneck to the overall performance of the cloud RAN. For example, these limitations may degrade the performance or capacity of the cloud RAN. Therefore, there is a need to test or verify the performance (or state) of the fronthaul network, and in particular the impact of the performance of the fronthaul network on the overall system performance, before the cloud RAN is actually deployed.

Many network test tools have been developed to test network performance such as availability, response time, utilization, throughput, bandwidth capacity, and the like. However, there are few tools designed for cloud RAN. In particular, there is no tool that can simulate the transmission in the fronthaul network between the cloud server and the RAP. Limitations of the front-end network may be exposed in the practical operation of the cloud RAN due to lack of valid authentication prior to deployment. However, the study of these limitations is very difficult, and thus these limitations may degrade the performance of the entire system.

Disclosure of Invention

In general, example embodiments of the present disclosure provide methods, apparatuses, and devices for fronthaul network authentication in cloud RANs.

In a first aspect, a method implemented at a cloud server in a RAN is provided. At an application running on a cloud server, a first message for a type of traffic is generated based on a traffic profile. The service profile is predefined for the RAN and associated with that type of service. The first message indicates a message format for a second message to be received from a RAP in the RAN. Causing the first message to be transmitted to the RAP. Based on the detection of the second message from the RAP, transmission characteristics of the type of traffic in the RAN are determined.

In a second aspect, a method implemented at a radio access point in a radio access network is provided. The method comprises the following steps: at an application running on a radio access point, obtaining a first message for a type of traffic from a cloud server in a radio access network, the first message generated by the cloud server based on a traffic profile, the traffic profile being predefined for the radio access network and associated with the type of traffic; determining a message format of a second message for the type of service from the first message; generating a second message in the determined message format; and causing the second message to be transmitted to the cloud server.

In a third aspect, an apparatus is provided that is implemented at a cloud server in a radio access network. The device comprises a service test module, wherein the service test module comprises: a first traffic module configured to generate a first message for a type of traffic based on a traffic profile, the traffic profile being predefined for the radio access network and associated with the type of traffic, the first message indicating a message format for a second message to be received from a radio access point in the radio access network; a first transmission module configured to cause a first message to be transmitted to a radio access point; an analysis module configured to determine a transmission characteristic of the type of traffic in the radio access network based on detection of the second message from the radio access point.

In a fourth aspect, an apparatus implemented at a radio access point in a radio access network is provided. The device comprises a service processing module, wherein the service processing module comprises: a receiving module configured to obtain a first message for a type of traffic from a cloud server in the radio access network, the first message generated by the cloud server based on a traffic profile, the traffic profile being predefined for the radio access network and associated with the type of traffic; a second service module including a format determination module configured to determine a message format of a second message for the type of service from the first message and a message generation module configured to generate the second message in the determined message format; and a third transmission module configured to cause the second message to be transmitted to the cloud server.

In a fifth aspect, there is provided a cloud server in a radio access network, the cloud server comprising: a processor; and a memory comprising instructions that, when executed by the processor, cause the cloud server to perform the method according to the first aspect.

In a sixth aspect, there is provided a radio access point in a radio access network, the radio access point comprising: a processor; and a memory comprising instructions which, when executed by the processor, cause the radio access point to perform the method according to the second aspect.

In a seventh aspect, a non-transitory computer-readable storage medium having a computer program stored thereon is provided. The computer program comprises instructions which, when executed by at least one processor, cause the at least one processor to carry out the method according to the first or second aspect.

It should be understood that this summary is not intended to identify key or essential features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become readily apparent from the following description.

Drawings

The foregoing and other objects, features, and advantages of the disclosure will be apparent from the following more particular description of some embodiments of the disclosure, as illustrated in the accompanying drawings, in which:

fig. 1 illustrates an example Radio Access Network (RAN) in which embodiments of the present disclosure may be implemented;

FIG. 2 illustrates an example structure of a business test module at a cloud server in accordance with some embodiments of the present disclosure;

fig. 3 illustrates an example aggregation of traffic flows in accordance with some embodiments of the present disclosure;

FIG. 4 illustrates an example structure of a traffic processing module at a RAP in accordance with some embodiments of the present disclosure;

FIG. 5 illustrates a flow diagram of an example method according to some embodiments of the present disclosure;

fig. 6 shows a flow diagram of an example method according to some other embodiments of the present disclosure; and

FIG. 7 illustrates a block diagram of a device suitable for implementing embodiments of the present disclosure.

Throughout the drawings, the same or similar reference numbers refer to the same or similar elements.

Detailed Description

Embodiments of the present disclosure will be described in more detail with reference to the accompanying drawings. While the drawings illustrate some embodiments of the disclosure, it should be understood that the disclosure may be implemented in various ways and should not be construed as limited to the embodiments set forth herein. Rather, the embodiments are provided for a more complete and complete understanding of the present disclosure. It should be understood that the drawings and the embodiments of the present disclosure are for illustration purposes only and do not set forth any limitations on the scope of the present disclosure.

As used herein, the term "terminal device" or "user equipment" (UE) refers to any terminal device capable of wireless communication with each other or a base station. As an example, the terminal device may include a Mobile Terminal (MT), a Subscriber Station (SS), a Portable Subscriber Station (PSS), a Mobile Station (MS), or an Access Terminal (AT), and the above-described devices mounted on a vehicle. In the context of the present disclosure, the terms "terminal device" and "user equipment" may be used interchangeably for purposes of discussion.

As used herein, the term "network device" refers to a base station or other entity or node that enables a terminal device to access a Radio Access Network (RAN). The term "base station" (BS) may denote a node B (NodeB or NB) and an evolved node B (eNode B or eNB). In the context of the present disclosure, the functionality of the network device is distributed over both the cloud server and the Radio Access Point (RAP) in the RAN.

As used herein, the term "cloud server" refers to a server or computing device that is located remotely from the RAP or baseband unit, e.g., in a data center. The cloud server may be implemented by a computer, mainframe, etc.

As used herein, the term "radio access point" (RAP) refers to a device having one or more radio frequency antennas that can transmit and/or receive radio signals to/from a terminal device.

As used herein, the term "include" and its variants should be understood as meaning open-ended terms of "including, but not limited to. The term "based on" should be understood as "based at least in part on". The term "one embodiment" should be understood as "at least one embodiment". The term "further embodiment" should be understood as "at least one further embodiment". Definitions related to other terms will be given in the following description.

As described above, there is a need to verify or test the performance or status of the fronthaul network between the cloud server and the RAP, and its impact on the cloud RAN. However, there is no means by which to simulate transmission in a forwarding network. Authentication of the forwarding network may require certain considerations including, for example, security, traffic characteristics, etc. For example, certain tools may not be authorized to run on the cloud server and/or RAP for security purposes.

In terms of traffic characteristics, the fronthaul traffic may be carried using various types of protocols, such as transmission control protocol/internet protocol (TCP/IP), stream Control Transmission Protocol (SCTP), user Datagram Protocol (UDP), and so on. Furthermore, the amount and speed of this type of traffic depends on different user scenarios, e.g. in the management plane (M-plane), control plane (C-plane) and user plane (U-plane). In actual deployment and service, traffic may pass through different paths in the cloud server and RAP, and the test tool needs to cover these specific paths accordingly.

In addition, in practice, engineers or operators are required to field test performance using test tools to dig as many problems as possible. However, the network configuration and test scenario for testing is different from the actual deployment and service. As a result, some potential problems may arise in the future. To date, there is no effective and efficient method to validate the fronthaul network between the cloud server and the RAP.

Embodiments of the present disclosure provide a framework for validating or testing a fronthaul network in a cloud RAN. In this framework, the means for authenticating may be arranged in both the cloud server and the RAP. The apparatus may be implemented in software, firmware, hardware, or any suitable combination thereof. For purposes of discussion, some embodiments of the disclosure will be discussed in the context of an apparatus implemented by a software application.

With these apparatuses, the cloud server and the RAP can generate and exchange traffic flows based on a traffic profile predefined for the cloud RAN. Based on the exchange of traffic flows, traffic transmission characteristics in the RAN may be determined, which may include delay, throughput, error rate, grant message format, and so on. Furthermore, the traffic transmission characteristics may be used to configure the base station functionality distributed on both the cloud server and the RAP.

Fig. 1 illustrates an example Radio Access Network (RAN) 100 in which embodiments of the present disclosure may be implemented. The RAN 100 includes a cloud server 105 and a RAP 110. It should be understood that the number of cloud servers and RAPs is shown for illustrative purposes only, and does not suggest any limitation. The RAN 100 may include any suitable number of cloud servers and RAPs.

As shown, the RAP 110 may wirelessly communicate with a terminal device 115. Further, the cloud server 10 may be connected to a core network (not shown). The cloud server 105 and the RAP 110 jointly implement the functionality of legacy network elements, such as base stations, in the RAN 100.

In this example, the RAN 100 also includes a router 120 between the cloud server 105 and the radio access point 110. The router 120 enables fronthaul communication between the cloud server 105 and the RAP 110. It should be understood that one router is shown for illustrative purposes only, and no limitation is set forth. Any suitable number of routers may be disposed between the cloud server 105 and the RAP 110. Further, other switching devices may be arranged in addition to one or more routers.

The fronthaul communication between the cloud server 105 and the RAP 110 may follow any suitable transport protocol. Examples of protocols may include, but are not limited to, transmission control protocol/internet protocol (TCP/IP), stream Control Transmission Protocol (SCTP), user Datagram Protocol (UDP), and the like.

In various embodiments of the present disclosure, two devices 125 and 130 (referred to as a "first device" 125 and a "second device" 130) are disposed in the cloud server 105 and the RAP 110, respectively. In this example, the first device 125 and the second device 130 are implemented by two applications. The first device 125 and the second device 130 may cooperate together to verify the fronthaul network between the cloud server 105 and the RAP 110.

As shown, the first device 125 includes a traffic testing module 135, the traffic testing module 135 may simulate fronthaul traffic based on a traffic profile 140, the traffic profile 140 may be predefined based on statistical information for different types of traffic in the RAN 100. The service profile 140 is associated with one or more services of that type. In some embodiments, the traffic profile 140 may be implemented by files formatted for M-plane, C-plane, and U-plane traffic. Further, the traffic profile 140 may define fronthaul communications in the RAN 100 such as UE attach, handover, tracking Area Update (TAU), paging and measurements, transport protocols, traffic volume and speed, etc., according to user scenarios.

FIG. 2 illustrates an example structure of the business test module 135, according to some embodiments of the disclosure. As shown in fig. 2, the traffic testing module 135 includes a traffic module 205 (referred to as a "first traffic module" 205), and the traffic module 205 generates a message (referred to as a "first message") for one type of traffic associated with the traffic profile 140. For example, the first traffic module 205 may retrieve the traffic profile 140 and then generate a first message based on the traffic profile 140.

The service profile 140 may be obtained in any suitable manner. In some embodiments, as shown in fig. 1, the first device 125 may include an interface module 145 (e.g., webUI) for obtaining the business profile 140 from user input. For example, a user (or operator or client) may log into cloud server 105 to load and configure business profile 140 via interface module 145. Further, interface module 140 may allow an operator to configure the transmission of cloud server 105 and retrieve the test results of the fronthaul network.

The first traffic module 205 may use the traffic profile 140 to generate the first message in any suitable manner. For example, the service profile 140 may define the size and format of the first message. In this example, the first traffic module 205 may generate a first message of a defined size and format. In embodiments where the traffic profile 140 also defines a transmission protocol, the first traffic module 205 may include a determination module (referred to as a "first determination module") for determining a transmission protocol for that type of traffic based on the traffic profile 140. The first traffic module 205 may also include a generation module (referred to as a "first generation module") for generating a first message based on the determined transmission protocol.

In some embodiments, the first message may be included in a traffic flow for that type of traffic (referred to as a "first traffic flow"). For example, the first generation module 205 may include a determination module (referred to as a "second determination module") for determining the amount and speed of the type of traffic based on the traffic profile 140, and a generation module (referred to as a "second generation module") for generating a first traffic flow based on the determined amount and speed.

In embodiments where the traffic profiles 140 are associated with different types of traffic, such as C-plane, U-plane, and M-plane traffic, the traffic testing module 135 may simulate a fronthaul traffic flow that aggregates multiple traffic flows for control plane signaling, user plane data transfer, and fronthaul traffic noise (such as supervision packets). For example, the traffic testing module 135 may include a module (not shown) to generate additional traffic flows (referred to as "second traffic flows") for additional types of traffic associated with the traffic profiles 140. In this example, the traffic testing module 135 may also include a module to aggregate the first traffic flow and the second traffic flow to generate an aggregated traffic flow.

In embodiments where the traffic profile 140 defines multiple user scenarios (such as UE attach, handover, TAU, paging, and measurements), the first traffic module 205 may generate a traffic flow for each user scenario and generate an aggregate traffic flow by accumulating the various user scenarios at a configured rate of occurrence over a unit of time. An example aggregation of traffic flows is shown in fig. 3. In this example, curves 305, 315, and 320 represent traffic flows in UE attach, handover, and measurement scenarios, respectively. Curve 325 represents the aggregate traffic flow. In addition, the simulation of the fronthaul traffic flow may use various types of traffic models, such as poisson traffic model, long tail traffic model, and so on.

Additionally, the first traffic module 205 considers load balancing so that no overload within the cloud server 105 or RAP 110 will occur. The first traffic module 205 may share the load at the application level. For example, for one task of one user case from the business profile 140, the first business module 205 can dynamically register the Consumer Product Information Database (CPID) with Retail and Consumer Products (RCPs) for message transmission and reception. Since RAPs can be distinguished by a Digital Signal Processor (DSP) core unit, the RAPs can be sequentially configured by the cloud server 105 in a round robin order based on user cases.

Still referring to fig. 2, the service test module 135 further includes a transmission module 210 (referred to as "first transmission module 210") for causing the first message to be transmitted to the RAP 130. The transmission may be implemented through, for example, the router 120 between the cloud server 105 and the RAP 110, and the communication modules of the cloud server 105 and the RAP 110.

In embodiments where the first message is included in the first traffic stream, the first transmission module 210 may cause the first traffic stream to be transmitted to the RAP 110. In embodiments where an aggregate traffic flow is generated, the transmission module 210 may cause transmission of the aggregate traffic flow.

In various embodiments of the present disclosure, the first message indicates a message format of a message (referred to as a "second message") to be received from the RAP 110. For example, the first message may have a message header indicating the size of the second message defined by the service profile 140. Thus, the RAP 110 may generate a second message having a size indicated by the first message. Embodiments at the RAP 110 will be discussed in the following paragraphs.

As shown in fig. 2, the first traffic module 135 also includes an analysis module 215. The analysis module 215 detects the second message from the RAP 110 and then determines the transmission characteristics of this type of traffic in the RAN 110. For example, if the second message is not detected, the analysis module 215 may determine that a corresponding transmission error occurred or that the RAP 110 does not allow the transmitted message type.

In some embodiments, the service profile 140 may also define an expiration time for detection. In this case, the analysis module 215 may include a determination module (referred to as a "third determination module") for determining a time period based on the traffic profile and a detection module for detecting the second message within the determined time period. For example, a timer is started after the transmission of the first message. If no message from the RAP 110 is detected at the expiration of the timer, the analysis module 215 may determine a transmission error or an unlicensed message type.

Next, still referring to fig. 1, in some embodiments, the first device 125 can integrate a tool module 150 (referred to as a "first tool module" 150), the tool module 150 for determining different transmission modes, such as transmission intervals between messages, transmission order of messages, and the like. In these embodiments, the traffic testing module 135 may include a generating module (referred to as a "third generating module") for generating additional messages (referred to as "third messages") for the type of traffic based on the traffic profile 140. The service test module 135 may include a transmission module (referred to as a "second transmission module") for causing the first message and the third message to be transmitted in the transmission mode determined by the first tool module 150.

The first apparatus 125 may further include a management module 155, and the management module 155 may switch between the first apparatus 125 and another apparatus (referred to as a "third apparatus") that enables the network device function of the cloud server 105. In this example, the third device is implemented by a software application similar to the first device 125 and the second device 130. It should be understood that the third means may be implemented in software, firmware, hardware or any suitable combination thereof.

For example, the management module 155 may include a switching module. The switching module may cause the third device to activate after the traffic test module 135 determines the transmission characteristics. In some embodiments, the third apparatus has been configured based on the determined transmission characteristics.

The application management module 155 may also manage upgrades of the first device 125 and further align upgrades of the cooperating first and

second devices

125, 130. For example, the management module 155 may include an indication module. If the code associated with the first apparatus 125 is upgraded, the indication module may cause an indication of the upgrade to be sent to the RAP 110 so that the code associated with the second apparatus 130 may be upgraded accordingly.

In some embodiments, the cloud server 105 may receive a request from the RAP 110 to upgrade code associated with the second device 130. In these embodiments, the management module 155 may include an upgrade module for causing upgrade data for code associated with the second device 130 to be transmitted to the RAP 110.

As shown in fig. 1, the first application 125 also includes an operations and maintenance (O & M) module 160, which O & M module 160 may be responsible for configuring fronthaul IP routing and transport routing, booting DSP software, configuring RAP hardware, and so forth. In some embodiments, the O & M module 160 may verify the connection between the cloud server 105 and the RAP 110. For example, the O & M module 160 may include a determining module (referred to as a "fourth determining module") that causes a request to be sent to the RAP 110. A fourth determination module then determines whether a response to the request is received from the RAP 110. If a response is received, a fourth determination module may determine that a link has been established between the cloud server 105 and the RAP 110. In some embodiments, the O & M module 160 may also include a routing module to configure a route for the cloud server 105 to communicate with the RAP 110 in the established link.

In various embodiments of the present disclosure, the second device 130 at the RAP 110 may cooperate with the first device 125 in the authentication of the fronthaul network between the cloud server 105 and the RAP 110. As shown in fig. 1, the second device 130 includes a traffic processing module 165 for processing messages or traffic flows for authentication.

Fig. 4 illustrates an example structure of a traffic processing module 165 according to some embodiments of the disclosure. As shown in fig. 4, the traffic processing module 165 includes a receiving module 405. The receiving module 405 obtains the first message from the cloud server 105. In embodiments where the first message is included in the first traffic flow, the receiving module 165 may include an acquiring module (referred to as a "first acquiring module") for acquiring the first traffic flow, and a further acquiring module (referred to as a "second acquiring module") for acquiring the first message from the first traffic flow. In embodiments where an aggregated traffic flow of a first traffic flow and a second traffic flow is transmitted from cloud server 105, receiving module 405 may obtain the aggregated traffic flow and obtain the first traffic flow from the aggregated traffic flow.

The traffic processing module 165 also includes a traffic module 410 (referred to as a "second traffic module 410"). The second service module 410 includes a format determining module for determining a message format of the second message from the first message, and a message generating module for generating the second message in the determined message format. In some embodiments, the message generation module may include a determination module (referred to as a "fifth determination module") for determining a transmission protocol for the first message, and a generation module (referred to as a "fourth generation module") for generating the second message using the determined transmission protocol.

As shown in fig. 4, the traffic processing module 165 further includes a transmission module 415 (referred to as a "third transmission module 415") that causes the second message to be transmitted to the cloud server 105.

Still referring to fig. 1, the second device 130 may include a tool module 170 (referred to as "second tool module 170") that cooperates with the first tool module 150 at the cloud server 105. In some embodiments, receiving module 405 may include an obtaining module (referred to as a "third obtaining module") for obtaining the first message and the third message from cloud server 105. After the acquisition, the second tool module 170 determines a transmission mode for the first message and the third message. The receiving module 405 may include an acquiring module (referred to as a "fourth acquiring module") for acquiring the first message based on the determined transmission mode.

The second device 130 may also include a management agent module 175 that cooperates with the management module 155 at the cloud server 105. Upon detecting an indication of an upgrade of code associated with the first apparatus 125, the management agent module 175 may cause a request to upgrade code associated with the second apparatus 130 to be sent to the cloud server 105. The request may also be transmitted automatically or autonomously by the RAT. The management agent module 175 may cause an upgrade of the code associated with the second apparatus 130 if upgrade data of the code associated with the second apparatus 130 is acquired from the cloud server 105.

As shown in fig. 1, the second device 130 further includes an O & M proxy module 180 that cooperates with the O & M module 160 at the cloud server 105. After obtaining the request from the cloud server 105, the O & M proxy module 180 may cause a response to the request to be sent to the cloud server 105.

Similar to the transmission and/or reception at the cloud server 105, for example, the transmission and/or reception may be implemented by, for example, the router 120 between the cloud server 105 and the RAP 110, and the communication modules of the cloud server 105 and the RAP 110.

It should be understood that all operations and features described above with respect to the first device 125 are equally applicable to the cooperating second device 130 and have similar effects. Details will be omitted for the sake of simplicity.

The modules and/or sub-modules included in the first device 125 and the second device 130 may be implemented in various ways, including software, hardware, firmware, or any combination thereof. In one embodiment, one or more modules may be implemented using software and/or firmware, e.g., machine executable instructions stored on a storage medium. Some or all of the modules in the

devices

125 and 130 may be implemented at least in part by one or more hardware logic components in addition to or in place of machine-executable instructions. By way of example, and not limitation, illustrative types of hardware logic components that may be used include Field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), system on a Chip Systems (SOCs), complex Programmable Logic Devices (CPLDs), and the like.

Fig. 5 shows a flowchart of an example method 500 according to some other embodiments of the present disclosure. The method 500 may be implemented by the first apparatus 125 at the cloud server 105 as shown in fig. 1, for example, by an application running on the cloud server 105. For discussion purposes, the method 500 will be described with reference to fig. 1.

As shown in fig. 5, at block 505, a first message for a type of traffic is generated based on the traffic profile 140. The service profile 140 is predefined for the RAN 100 and is associated with that type of service. The first message indicates a message format for the second message to be received from the RAP 110. At block 510, a first message is transmitted to the RAP 110. At block 515, transmission characteristics of the type of traffic in the RAN 100 are determined based on detection of the second message from the RAP 110.

In some embodiments, a transport protocol may be determined for this type of traffic based on the traffic profile 140. The first message may be generated using the determined transmission protocol.

In some embodiments, the first message may be included in a first traffic flow for the type of traffic. In these embodiments, the amount and speed of this type of traffic may be determined based on the traffic profile 140. A first traffic flow may then be generated based on the determined quantity and speed.

In some embodiments, the service profile 140 may also be associated with additional types of services. A second traffic flow for the additional type of traffic may be generated based on the traffic profile, and the first traffic flow and the second traffic flow may be aggregated.

In some embodiments, the time period may be determined based on a traffic profile. A second message from the radio access point is detected within the determined time period.

In some embodiments, the transmission characteristics may include at least one of a delay, a throughput, an error rate, and a grant message format for the type of traffic.

In some embodiments, the service profile 1400 may be obtained from user input.

In some embodiments, the traffic profile may be predefined based on statistical information for this type of task in the RAN 100. In some embodiments, the type of traffic may include one of control plane traffic, user plane traffic, and management plane traffic.

In some embodiments, at least one third message for a type of traffic may be generated based on the traffic profile. A transmission mode may be determined for the first message and the at least one third message. The first message and the at least one third message may then be transmitted to the RAP 110 in the determined transmission mode.

In some embodiments, after the determination of the transmission characteristic, a further application may be launched at the cloud server. Further applications enable cloud server 105 to function as a network device in RAN 100.

In some embodiments, the further application is configured prior to start-up based on the determined transmission characteristics.

In some embodiments, after an upgrade of code associated with an application at the cloud server 105, an indication of the upgrade may be sent to the radio access point to cause an upgrade of code associated with the collaborative application at the RAP 110.

In some embodiments, upgrade data for code associated with a cooperating device may be transmitted to the RAP 110 upon detecting a request from the RAP 110 to upgrade the code associated with the cooperating device.

In some embodiments, the request may be sent to the RAP 110. It may be determined whether a response to the request is received from the RAP 110. If it is determined that a response is received from the RAP, it may be determined that a link has been established between the cloud server 105 and the RAP 110. In some embodiments, the route may be configured in the established link.

Fig. 6 illustrates a flow diagram of an example method 600 in accordance with some other embodiments of the present disclosure. The method 600 may be implemented by the second device 130 at the RAP 110 as shown in FIG. 1, for example, by an application running on the RAP 110. For discussion purposes, the method 600 will be described with reference to fig. 1.

As shown in fig. 6, at block 605, a first message for a type of traffic is obtained from cloud server 105. At block 610, a message format of a second message for the type of traffic is determined from the first message. At block 615, a second message is generated in the determined message format. At block 620, a second message is transmitted to cloud server 620.

In some embodiments, a transmission protocol for the first message may be determined. The second message may be generated using the determined transmission protocol.

In some embodiments, a first traffic flow for the type of traffic may be obtained from cloud server 105. The first traffic flow includes a first message. The first message may then be obtained from the first traffic flow.

In some embodiments, an aggregate traffic flow of the first traffic flow and the second traffic flow for additional types of traffic may be obtained from cloud server 105. A first traffic flow may be obtained from the aggregated traffic flow.

In some embodiments, the first message and the at least one third message for the type of traffic may be obtained from a cloud server. A transmission mode for the first message and the at least one third message may be determined. The first message may then be acquired based on the determined transmission mode.

In some embodiments, after detecting an indication of an upgrade of code associated with a collaborative application at cloud server 105, a request to upgrade code associated with the application may be sent to cloud server 105. Upgrade data for code associated with an application may be obtained from cloud server 105. Code associated with the application may be upgraded based on the upgrade data.

In some embodiments, after obtaining the request from cloud server 105, a response to the request may be sent to cloud server 105.

It should be understood that all operations and features related to the cloud server 105 and RAP 110 described above with reference to fig. 1-4 are equally applicable to the

methods

500 and 600, and have similar effects. Details will be omitted for the sake of simplicity.

Fig. 7 illustrates a block diagram of a device 700 suitable for implementing embodiments of the present disclosure. The device 700 may be used to implement a cloud server, such as the cloud server 105 shown in fig. 1, and/or a RAP, such as the RAP 110 shown in fig. 1.

As shown in fig. 7, the device 700 includes a controller 710 that controls the operation and functions of the device 700. In some embodiments, controller 710 may perform various operations, for example, by way of instructions 730 stored in a memory 720 coupled to controller 710. The memory 720 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, including but not limited to semiconductor-based memory devices, magnetic memory devices and systems, and optical memory devices and systems. Although only one memory unit is shown in FIG. 7, device 700 may include several physically distinct memory units.

The controller 710 may be of any type suitable to the local technical environment, and may include, but is not limited to, one or more of general purpose computers, special purpose computers, microcontrollers, digital Signal Processors (DSPs), and controller-based multi-core controller architectures. The apparatus may also include a plurality of controllers 710. The controller 710 is coupled to the transceiver 740. The transceiver 740 may receive and transmit information via one or more antennas, cables, or optical fibers and/or other components.

When device 700 is operating as cloud server 105, controller 710 and transceiver 740 may cooperate to perform method 500 as described above with reference to fig. 5. When the device 700 is acting as a RAP 110, the controller 710 and the transceiver 740 may cooperate to perform the method 600 as described above with reference to FIG. 6. In some embodiments, for example, all acts described above in connection with data/information transmission and reception may be performed by the transceiver 740, while other acts may be performed by the controller 710. All features described with reference to fig. 1 to 6 are applicable to the device 700 and will not be described again here.

In general, the various example embodiments of this disclosure may be implemented in hardware, special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of the embodiments of the disclosure are illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

By way of example, embodiments of the disclosure may be described in the context of machine-executable instructions, included in program modules, executed in a device on a target physical or virtual processor. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functionality of the program modules may be combined or divided between program modules. Machine-executable instructions for program modules may be executed within local or distributed devices. In a distributed facility, program modules may be located in both local and remote memory storage media.

Computer program code for performing the methods of the present disclosure may be written in any combination of one or more programming languages. The computer program code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the computer or other programmable data processing apparatus, causes the functions/acts specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote computer or entirely on the remote computer or server.

In the context of this disclosure, a machine-readable medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium and may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination thereof. More specific examples of a machine-readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure, but rather as descriptions of features specific to particular embodiments. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Although the disclosure has been described in language specific to structural features and/or methodological acts, it is to be understood that the disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A method implemented at a cloud server in a radio access network, comprising:

at an application running on the cloud server,

generating a first message for a type of traffic based on a traffic profile, the traffic profile being predefined for the radio access network and associated with the type of traffic, the first message indicating a message format for a second message to be received from a radio access point in the radio access network;

causing the first message to be transmitted to the radio access point; and

determining a transmission characteristic of the type of traffic in the radio access network based on the detection of the second message from the radio access point.

2. The method of claim 1, wherein generating the first message comprises:

determining a transport protocol for the type of traffic based on the traffic profile; and

generating the first message using the determined transmission protocol.

3. The method of claim 1, wherein the first message is included in a first traffic flow for the type of traffic, generating the first message comprising:

determining a quantity and a speed of the type of traffic based on the traffic profile; and

generating the first traffic flow based on the determined number and the speed.

4. The method of claim 1, wherein determining the transmission characteristic comprises:

determining a time period based on the traffic profile; and

detect the second message from the radio access point within the determined time period.

5. The method of claim 1, further comprising:

the service profile is obtained from user input.

6. The method of claim 1, further comprising:

generating at least one third message for the type of traffic based on the traffic profile; and

determining a transmission mode for the first message and the at least one third message; and is

Wherein causing the first message to be transmitted comprises causing the first message and the at least one third message to be transmitted to the radio access point in the determined transmission mode.

7. The method of claim 1, further comprising:

subsequent to the determination of the transmission characteristics, causing a launching of a further application at the cloud server, the further application enabling the cloud server to function as a network device in the radio access network.

8. The method of claim 7, further comprising:

configuring, prior to the launching, the further application based on the determined transmission characteristics.

9. The method of claim 1, further comprising:

in response to an upgrade of code of the application, cause an indication of the upgrade to be sent to the radio access point to cause an upgrade of code associated with a cooperating application at the radio access point.

10. The method of claim 9, further comprising:

in response to detecting a request from the radio access point to upgrade the code associated with the cooperating application, causing upgrade data for the code associated with the cooperating application to be transmitted to the radio access point.

11. The method of any of claims 1 to 10, further comprising:

causing a request to be sent to the radio access point;

determining whether a response to the request is received from the radio access point; and

determining that a link has been established between the cloud server and the radio access point in response to determining that the response is received from the radio access point.

12. The method of claim 11, further comprising:

configuring a route in the established link.

13. A method implemented at a radio access point in a radio access network, the method comprising:

at an application running on the radio access point,

obtaining, from a cloud server in the radio access network, a first message for a type of traffic, the first message generated by the cloud server based on a traffic profile, the traffic profile being predefined for the radio access network and associated with the type of traffic;

determining a message format of a second message for the type of traffic from the first message;

generating the second message in the determined message format; and

causing the second message to be transmitted to the cloud server.

14. The method of claim 13, wherein generating the second message comprises:

determining a transport protocol to be used for the first message; and

generating the second message using the determined transmission protocol.

15. The method of claim 13, wherein obtaining the first message comprises:

obtaining a first traffic flow for the type of traffic from the cloud server, the first traffic flow including the first message; and

and acquiring the first message from the first service flow.

16. The method of claim 13, wherein obtaining the first message comprises:

obtaining the first message and at least one third message for the type of traffic from the cloud server, and

determining a transmission mode to be used for the first message and the at least one third message; and

obtaining the first message based on the determined transmission mode.

17. The method of claim 13, further comprising:

in response to detecting at the cloud server an indication of an upgrade to code associated with a collaborative application, causing a request to upgrade code associated with the application to be sent to the cloud server;

obtaining upgrade data for the code associated with the application from the cloud server; and

cause the code associated with the application to be upgraded based on the upgrade data.

18. The method of any of claims 13 to 17, further comprising:

in response to obtaining a request from the cloud server, causing a response to the request to be sent to the cloud server.

19. An apparatus implemented at a cloud server in a radio access network, the apparatus comprising:

a service test module comprising:

a first traffic module configured to generate a first message for a type of traffic based on a traffic profile, the traffic profile being predefined for the radio access network and associated with the type of traffic, the first message indicating a message format for a second message to be received from a radio access point in the radio access network;

a first transmission module configured to cause the first message to be transmitted to the radio access point;

an analysis module configured to determine a transmission characteristic of the type of traffic in the radio access network based on detection of the second message from the radio access point.

20. The apparatus of claim 19, wherein the first traffic module comprises:

a first determination module configured to determine a transport protocol for the type of traffic based on the traffic profile; and

a first generating module configured to generate the first message using the determined transmission protocol.

21. The apparatus of claim 19, wherein the first message is included in a first traffic flow for the type of traffic, and the first traffic module comprises:

a second determination module configured to determine the amount and speed of the type of traffic based on the traffic profile; and

a second generation module configured to generate the first traffic flow based on the determined quantity and the speed.

22. The apparatus of claim 19, wherein the analysis module comprises:

a third determination module configured to determine a time period based on the traffic profile; and

a detection module configured to detect the second message from the radio access point within the determined time period.

23. The apparatus of claim 19, further comprising:

an interface module configured to obtain the service profile from a user input.

24. The apparatus of claim 19, wherein the traffic testing module further comprises a third generating module configured to generate at least one third message for the type of traffic based on the traffic profile,

wherein the apparatus further comprises a tool module configured to determine a transmission mode for the first message and the at least one third message; and is

Wherein the first transmission module comprises a second transmission module configured to cause the first message and the at least one third message to be transmitted to the radio access point in the determined transmission mode.

25. The apparatus of claim 19, further comprising:

a management module comprising:

a switching module configured to cause, subsequent to the determination of the transmission characteristics, a start-up of a further apparatus at the cloud server, the further apparatus configured to enable the cloud server to function as a network device in the radio access network.

26. The apparatus of claim 25, wherein the further apparatus at the cloud server has been configured based on the determined transmission characteristic.

27. The apparatus of claim 25, wherein the management module further comprises:

an indication module configured to cause an indication of the upgrade to be transmitted to the radio access point in response to an upgrade of code associated with the apparatus to cause an upgrade of code associated with a collaborative application at the radio access point.

28. The apparatus of claim 27, wherein the management module further comprises:

an upgrade module configured to cause upgrade data for the code associated with the cooperative application to be transmitted to the radio access point in response to detecting a request from the radio access point to upgrade the code associated with the cooperative application.

29. The apparatus of any of claims 19 to 28, further comprising:

an operation and maintenance module comprising a fourth determination module configured to:

causing a request to be sent to the radio access point;

30. The apparatus of claim 29, wherein the operation and maintenance module further comprises:

a routing module configured to configure a route in the established link.

31. An apparatus implemented at a radio access point in a radio access network, the apparatus comprising:

a service processing module, comprising:

a receiving module configured to obtain a first message for a type of traffic from a cloud server in the radio access network, the first message generated by the cloud server based on a traffic profile, the traffic profile being predefined for the radio access network and associated with the type of traffic;

a second service module comprising:

a format determination module configured to determine a message format of a second message for the type of traffic from the first message, an

A message generation module configured to generate the second message in the determined message format; and

a third transmission module configured to cause the second message to be transmitted to the cloud server.

32. The apparatus of claim 31, wherein the message generation module comprises:

a fifth determining module configured to determine a transport protocol used for the first message; and

a fourth generation module configured to generate the second message using the determined transmission protocol.

33. The apparatus of claim 31, wherein the receiving means comprises:

a first obtaining module configured to obtain a first traffic flow for the type of traffic from the cloud server, the first traffic flow including the first message; and

a second obtaining module configured to obtain the first message from the first service flow.

34. The apparatus of claim 31, wherein the receiving means comprises:

a third obtaining module configured to obtain the first message and at least one third message for the type of traffic from the cloud server,

wherein the apparatus further comprises a second tool module configured to determine a transmission mode used for the first message and the at least one third message; and is

Wherein the receiving module further comprises a fourth obtaining module configured to obtain the first message based on the determined transmission mode.

35. The apparatus of claim 31, further comprising:

a management agent module configured to:

in response to detecting an indication of an upgrade of code associated with a collaborative application at the cloud server, causing a request to upgrade code associated with the apparatus to be sent to the cloud server;

obtaining upgrade data for the code associated with the apparatus from the cloud server; and

cause the code associated with the apparatus to be upgraded based on the upgrade data.

36. The apparatus of any of claims 31 to 35, further comprising:

an operation and maintenance agent module configured to cause a response to a request from the cloud server to be sent to the cloud server in response to obtaining the request.

37. A cloud server in a radio access network, comprising:

a processor; and

memory comprising instructions that, when executed by the processor, cause the cloud server to perform the method of any of claims 1 to 12.

38. A radio access point in a radio access network, comprising:

a processor; and

a memory comprising instructions that, when executed by the processor, cause the radio access point to perform the method of any one of claims 13 to 18.

39. A non-transitory computer-readable storage medium having stored thereon a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 12.

40. A non-transitory computer-readable storage medium having stored thereon a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to perform the method according to any one of claims 13 to 18.