Method, device and equipment for converting from IP flow-free to domain name flow-free based on CDN
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- YUNZHOU TIMES TECHNOLOGY CO LTD
- Filing Date
- 2026-03-05
- Publication Date
- 2026-06-02
Smart Images
Figure CN122137824A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication network technology, and in particular to a method, apparatus and equipment for converting from IP-based free traffic to domain-based free traffic based on CDN. Background Technology
[0002] In the context of the rapid development of the mobile internet, data-intensive applications such as high-definition video and interactive live streaming have become mainstream. To enhance user activity and stickiness, basic telecommunications operators have partnered extensively with mainstream internet content service providers to launch "targeted data-free" services. This service allows users to access designated content using specific partner applications without having their mobile data usage counted towards their personal data plan, thus lowering the barrier to entry for users. The implementation of this service relies heavily on the operator's network side's accurate identification of user data traffic and real-time policy enforcement capabilities.
[0003] Currently, most mainstream targeted data-free technologies employ a whitelist mechanism based on IP addresses. The typical process is as follows: After a user initiates a resource request through a partner application, the content delivery network's scheduling service returns a resource access link pointing to a specific edge node IP address. The application client then sends the actual media stream request to that IP address. When the data stream passes through the carrier network, policy enforcement points deployed on the core network path (such as dedicated data-free gateways or DPI devices) detect the target IP address. If the IP address exists in the pre-configured "data-free IP address pool" whitelist, this data stream is marked as free-of-charge traffic. In this mode, the IP address acts as the unique identifier for the data-free policy.
[0004] However, this IP-based mechanism has significant systemic flaws and is ill-suited to the dynamic and complex nature of modern internet services. First, its scalability and operational agility are poor. The edge node IP address pools of large CDN networks frequently change due to expansion, failover, or multi-cloud deployment. Each change requires manual updates to core network element policies by the operator, a lengthy process that cannot be implemented in real time, easily leading to user complaints due to policy asynchrony. Second, security and compliance risks are prominent. IP addresses themselves lack business semantics; the same IP may carry cooperative content that should be exempt from data usage, third-party advertisements that should not be exempt, and user behavior data. A broad-based IP-level data exemption approach can easily lead to policy generalization and potential revenue loss, and it also fails to meet regulatory requirements for auditable and traceable data exemption traffic. Third, business flexibility is severely limited. IP whitelists cannot support fine-grained control of data exemption policies based on content type, user level, or region, hindering refined operations and business innovation. Finally, there are blind spots in user experience. Users cannot find detailed information about the data exemption consumed by each application in their bills, resulting in weak awareness of their rights and difficulties in assigning responsibility to customer service. Therefore, the industry is actively exploring the evolution towards a more refined and secure free-traffic mechanism based on domain names. However, how to achieve a seamless and smooth migration from the existing IP mechanism to the new mechanism has become a technical issue that urgently needs to be addressed. Summary of the Invention
[0005] Based on this, this application provides a method for switching from IP-based free traffic to domain-based free traffic based on CDN, characterized by including: Based on the data-free requirements of partner apps, exclusive data-free domains are obtained from the established domain name binding relationships to build a network strategy foundation that supports fine-grained identification and statistics; Based on the resource scheduling request and scheduling result initiated by the APP, a resource access URL is generated and returned that replaces the target node IP address with the free-flow domain name, triggering subsequent network requests based on the domain name; Based on the resource request carrying the dedicated free-flow domain name and the established domain name binding relationship, the free-flow policy is executed through the operator's free-flow gateway, traffic is counted at the APP level and the request is routed to the CDN node, and the traffic is converted into a free-flow service state.
[0006] Optionally, based on the data-free requirements of partner apps, a dedicated data-free domain name is obtained from the established domain name binding relationship to build a network policy foundation that supports fine-grained identification and statistics, including: Based on the identifier of the cooperating APP, a query request is initiated to the established domain name binding relationship to obtain the exclusive free-traffic domain name bound to the APP; Based on the obtained dedicated free-traffic domain name, generate policy configuration data containing the free-traffic domain name; The policy configuration data is applied to the processing of subsequent resource scheduling requests to enable domain-based free traffic identification logic.
[0007] Optionally, the step of generating and returning a resource access URL that replaces the target node's IP address with the free-traffic domain name based on the resource scheduling request and scheduling result initiated by the APP, and triggering subsequent network requests based on the domain name, includes: Based on the resource scheduling request sent by the APP client, receive and parse the request, and extract user context information, resource path and query parameters; Based on the parsed user context information, the node selection logic is executed to determine a target node from the edge node cluster and obtain the IP address of the target node; Based on the IP address of the target node, the resource path and query parameters, and the exclusive free-flow domain name obtained for the APP, a URL rewriting operation is performed to generate an access address that uses the free-flow domain name as the network location identifier and includes the resource path and query parameters. Based on the generated access address, an HTTP response message is constructed and returned to the APP client, causing the APP client to initiate a resource acquisition request based on the access address.
[0008] Optionally, the step of executing the free-traffic policy through the operator's free-traffic gateway based on the resource request carrying the dedicated free-traffic domain name and the established domain name binding relationship, counting traffic by APP dimension and routing the request to CDN nodes, and converting the traffic into a free-traffic service state includes: Based on the secure connection request initiated by the APP client according to the access address, the operator's free data gateway intercepts the connection establishment process at the transport layer and extracts the target domain name from the server identifier field in the security protocol or the host field in the application layer protocol header. Based on the extracted target domain name, the operator's free data gateway queries the locally loaded free data domain name binding policy library and performs a matching operation to obtain the corresponding APP identifier; Based on the APP identifier obtained through matching, the operator's free data gateway executes billing exemption and traffic statistics instructions on the network data stream corresponding to the connection; After executing the billing exemption and traffic statistics instructions, the operator's free traffic gateway routes the resource acquisition request message to the destination CDN edge node.
[0009] Optionally, the step of performing a URL rewriting operation based on the IP address of the target node, the resource path and query parameters, and the dedicated free-data domain name obtained for the APP, to generate an access address that uses the free-data domain name as a network location identifier and includes the resource path and query parameters, includes: Based on the IP address of the target node and the dedicated free-traffic domain name, perform host identifier replacement, replacing the network location portion in the original access address based on the IP address with the free-traffic domain name; Based on the resource path and query parameters, perform resource path concatenation, appending the complete resource path and query parameters to the address with the free-flow domain name as the network location identifier, to form the final resource access URL.
[0010] Optionally, the step of constructing an HTTP response message based on the generated access address and returning it to the APP client, so that the APP client initiates a resource acquisition request based on the access address, includes: Based on the generated resource access URL, it is used as the response body content, encapsulated into a standard HTTP success response message, and the HTTP success response message is sent to the APP client.
[0011] Optionally, the step of executing billing exemption and traffic statistics instructions on the network data stream corresponding to the connection by the operator's free data gateway based on the APP identifier obtained through matching includes: Based on the APP identifier obtained through matching, a free-of-charge flag is added to the data packets corresponding to the connection; Based on the APP identifier and the real-time byte count of the data flow through the gateway, the traffic data is updated to the independent statistical storage unit according to the APP to which it belongs.
[0012] This application also provides a device for switching from IP-based free traffic to domain-based free traffic based on CDN, the device comprising: The free data policy basic construction module is used to obtain exclusive free data domains from the established domain name binding relationship based on the free data requirements of cooperative apps, and build a network policy foundation that supports fine-grained identification and statistics. The free-data access address generation module is used to generate and return a resource access URL that replaces the target node IP address with the free-data domain name based on the resource scheduling request and scheduling result initiated by the APP, and trigger subsequent network requests based on the domain name; The free-traffic policy execution and traffic statistics module is used to execute the free-traffic policy through the operator's free-traffic gateway based on the resource request carrying the exclusive free-traffic domain name and the established domain name binding relationship, to count traffic by APP dimension and route the request to CDN node, and to convert the traffic into a free-traffic service state.
[0013] Optionally, the free access address generation module further includes: The scheduling decision and IP acquisition module is used to parse and extract the scheduling context based on the resource scheduling request sent by the APP client, execute the node selection algorithm to determine the target node and obtain its IP address; The free-flow domain name replacement URL generation module is used to perform host identifier replacement and path concatenation based on the target node IP address, resource path and query parameters, and exclusive free-flow domain name to generate an access address with the free-flow domain name as the network location identifier; The transparent response triggering module is used to encapsulate the generated free access address into a standard HTTP response and return it to the APP client to trigger subsequent free resource requests based on the domain name.
[0014] This application also provides an electronic device for implementing any of the described CDN-based methods for switching from IP-based free traffic to domain-based free traffic, including: The processor is used to execute the complete process of obtaining a dedicated free-flow domain name from the established domain name binding relationship to build the network policy foundation based on the free-flow request of the cooperative APP, generating and returning a resource access URL that replaces the target node IP address with the free-flow domain name according to the resource scheduling request initiated by the APP, and executing the free-flow policy through the operator's free-flow gateway according to the resource request carrying the dedicated free-flow domain name, and statistically analyzing traffic by APP dimension and routing the request to CDN node, thereby converting the traffic into a free-flow service state. The storage device is used to store established domain name binding relationships, free data access addresses generated for apps, matched app identifiers, and free data usage data statistically analyzed by app dimension.
[0015] The beneficial effects of this application are as follows: By dynamically replacing the CDN target node IP address with a dedicated free-traffic domain name, the resource scheduling logic and the execution of the free-traffic policy are decoupled, ensuring that the flexibility of CDN network dynamic scheduling is not interfered with by the free-traffic service; by enabling the operator's free-traffic gateway to identify the APP identity in real time based on the domain name, execute refined free-traffic policies, and count traffic by APP dimension, the transformation and upgrading from "pipeline-like" extensive free-traffic to "business-oriented" precise free-traffic service is achieved; and by constructing a fully automated closed loop from domain name binding and scheduling conversion to gateway identification and statistics, while ensuring a seamless user experience, an accurate and reliable data foundation is provided for the operator's refined operation and billing settlement. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings required in the description of the embodiments or the prior art are briefly introduced below. Obviously, the accompanying drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0017] Figure 1 This application presents a flowchart illustrating a specific embodiment of a CDN-based method for switching from IP-based free traffic to domain-based free traffic. Figure 2 This document illustrates a flowchart of an embodiment of a CDN-based method for switching from IP-based free-flow to domain-based free-flow. Figure 3 This is a block diagram of a device for converting from IP-based free traffic to domain-based free traffic according to a specific embodiment of this application. Detailed Implementation
[0018] Various exemplary embodiments, features, and aspects of this application will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.
[0019] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.
[0020] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.
[0021] Furthermore, to better illustrate this application, numerous specific details are provided in the following detailed embodiments. Those skilled in the art should understand that this application can be implemented without certain specific details. In some instances, methods, means, components, and circuits well-known to those skilled in the art have not been described in detail in order to highlight the main points of this application.
[0022] This application proposes a CDN-based method for switching from IP-based free traffic to domain-based free traffic, addressing the technical challenge of adapting traditional free traffic solutions relying on fixed IPs or APNs to business-level refined operations in a CDN environment. The core of this application lies in creatively decoupling the CDN resource scheduling process from the free traffic policy execution process. First, the system dynamically allocates a dedicated free traffic domain name from pre-defined binding relationships based on the free traffic requirements of the cooperating app, establishing the policy foundation. Then, in the resource scheduling phase, the system replaces the target CDN node IP address in the scheduling result with this dedicated free traffic domain name in real time, generating a new access address and returning it to the app client, thereby "guiding" subsequent resource requests to the domain name-based identification channel. Finally, the free traffic gateway deployed on the operator's side intercepts these requests carrying the dedicated domain name, extracts the domain name, matches the app's identity, performs free traffic billing exemption and traffic statistics, and then accurately routes the request to the original target CDN node to complete resource acquisition. This application cleverly achieves traffic coloring and identification by using domain names as an intermediate identifier, without altering existing CDN scheduling logic and APP client behavior. This enables operators to precisely control, measure in real time, and automate the operation of free data services at the granular level of the APP. This application effectively supports the large-scale and refined deployment of free data services in complex CDN networks, significantly improving operational efficiency and billing accuracy.
[0023] Example 1 like Figure 1 The diagram shown is a flowchart of a method for switching from IP-based free traffic to domain-based free traffic based on CDN according to an embodiment of this application. The method specifically includes the following: S100, based on the data-free requirements of partner apps, obtains exclusive data-free domains from established domain name binding relationships, and builds the foundation for network strategies that support fine-grained identification and statistics.
[0024] Specifically, the system initiates a query request to a pre-configured and maintained domain name binding relationship database based on the unique identifier of the cooperating app. This binding relationship defines the mapping between the app identifier and the dedicated free-traffic domain name. After obtaining the corresponding dedicated free-traffic domain name, the system uses it as a core configuration element to generate structured policy configuration data. This policy configuration data not only contains the free-traffic domain name string but also carries the identification logic definition required for subsequent processes. After generation, this policy configuration data is dynamically loaded into the policy execution environment, thereby establishing the ability to identify apps based on domain names within the system, laying the data foundation for subsequent free-traffic policy execution and traffic statistics. The entire process ensures that each cooperating app has its own independent and traceable domain name identifier, enabling network traffic to be accurately associated with specific app services in subsequent stages, realizing policy preparation from coarse-grained free-traffic at the connection level to fine-grained free-traffic at the business level.
[0025] S200: Based on the resource scheduling request and scheduling result initiated by the APP, generate and return a resource access URL that replaces the target node IP address with the free-flow domain name, triggering subsequent network requests based on the domain name.
[0026] Specifically, when an app client initiates a resource scheduling request, the system receives and parses the request, extracting user context information and resource location parameters. Based on the user context information, the system executes a predetermined node selection algorithm to determine an optimal target node from the edge node cluster of the distributed content delivery network (CDN) and obtains the network protocol (IP) address of that node. Subsequently, the system performs a core URL rewriting operation to replace the target node's IP address with the obtained dedicated free-traffic domain name as a new network location identifier, while maintaining the original request's resource path and query parameters intact, thus constructing a new resource access address guided by the dedicated free-traffic domain name. Finally, the system encapsulates this newly generated access address into a standard HTTP response message and returns it to the app client. The client will then initiate an actual resource acquisition request based on this address, thereby directing traffic to the domain name-based identification channel, creating the prerequisites for the execution of the free-traffic policy, and the entire process is transparent to the app client.
[0027] S300: Based on the resource request carrying the dedicated free-flow domain name and the established domain name binding relationship, the free-flow policy is executed through the operator's free-flow gateway, traffic is counted at the APP level and the request is routed to the CDN node, and the traffic is converted into a free-flow service state.
[0028] Specifically, when an app client initiates a secure connection request based on the aforementioned access address, the free-flow gateway deployed on the carrier network intercepts the connection establishment process at the transport layer and extracts the target domain name from the security protocol handshake phase or the application layer protocol header. The gateway then queries its locally loaded free-flow domain name binding policy library, which is identical to the one used in step S100, and matches the extracted target domain name with records in the library to accurately obtain the identity of the app issuing the request. Upon successful matching, the gateway performs a dual-core operation based on the app identifier: firstly, it adds a free-of-charge flag to the network data stream corresponding to this connection, instructing the billing system to grant exemption; secondly, it performs real-time byte counting of the flowing data packets and aggregates the statistical results by app identifier, updating them to an independent usage statistics unit. After completing policy execution and statistics, the gateway accurately routes the original, untampered resource acquisition request message to the CDN edge node it originally intended to access, ensuring normal resource acquisition. Thus, traffic is converted to a free-flow service state without the user's awareness, while simultaneously achieving accurate business-level statistics.
[0029] In summary, this application addresses the core pain points of traditional data-free technologies in dynamic CDN network environments, which are difficult to adapt to and unable to achieve refined business-level operations, and proposes a systematic solution. First, it breaks away from the traditional model of relying on fixed IPs or APNs for extensive data-free operations, constructing a refined data-free strategy foundation based on dedicated domain name binding. By dynamically allocating and maintaining a dedicated data-free domain name for each cooperating app and generating it as loadable policy configuration data, the data-free rules are elevated from the network or connection layer to the business identification layer. This provides subsequent processes with a unique identification basis using the "domain name" as a key, accurately traceable to the specific app's business, achieving a strong association between the data-free strategy and the specific business identity from the source, laying the foundation for refined operations. Second, addressing the dynamic contradiction between CDN resource scheduling results (target node IP) and data-free identification requirements (dedicated domain name), a transparent data-free identification conversion mechanism centered on URL rewriting is designed. When an app initiates a scheduling request, the system retains the original resource location information while seamlessly and in real-time replacing the specific CDN node IP address returned by the scheduling with a dedicated free-traffic domain name pre-assigned to the app, generating a new access address and returning it to the client. This mechanism cleverly decouples the dynamic CDN resource scheduling link from the stable free-traffic policy execution link, ensuring that the final resource request naturally carries a domain name identifier for business identification. This creates the necessary conditions for accurate identification by the operator, and the entire process is completely transparent to the app client, requiring no modification. Finally, to meet the operator's needs for accurate identification, policy execution, and data statistics of massive encrypted mixed traffic, a free-traffic policy execution and closed-loop statistics system based on real-time domain name matching was constructed. The free-traffic gateway deployed on the operator's network extracts the target domain name from the connection establishment process using deep packet inspection technology and quickly matches the corresponding app identifier. Based on this identifier, two core operations are executed simultaneously: adding a bill-free tag to the data stream to achieve fee exemption, and performing real-time traffic statistics by app dimension. After completing the business processing, the gateway accurately routes the original request to the target CDN node, ensuring smooth business operation. This not only enables automated, free-of-charge processing of user-side traffic, but also generates accurate free-of-charge data at the APP level on the operator's side, providing reliable data support for cost accounting, resource monitoring, and business settlement, thus realizing a complete closed loop from technical identification to commercial operation.
[0030] As an optional implementation of this application, optionally, in step S100, based on the data-free requirements of the cooperating APP, a dedicated data-free domain name is obtained from the established domain name binding relationship to construct a network policy foundation that supports refined identification and statistics, including: 110. Based on the identifier of the cooperating APP, initiate a query request to the established domain name binding relationship to obtain the exclusive free-traffic domain name bound to the APP.
[0031] Specifically, when the system initializes or responds to a new cooperative APP access request, it initiates the basic construction process for the free-data policy. This process begins with a structured query operation. The system uses the cooperative APP's unique identifier, such as its globally unique package name or assigned APP ID, as the query key to launch a precise query request to the persistently stored domain name binding relationship. This established domain name binding relationship is a pre-configured data structure that maintains a strict mapping relationship between the APP identifier and the dedicated free-data domain name, typically stored in a configuration database or configuration center. This query request is initiated through a predefined configuration management interface, aiming to retrieve one or more pre-assigned dedicated free-data domain names that are tightly bound to the APP identifier. The obtained dedicated free-data domain name is a unique string conforming to the Internet Domain Name System specifications. This domain name will be the fundamental basis for policy matching and traffic attribution determination in subsequent steps.
[0032] 120. Based on the obtained exclusive free-traffic domain name, generate policy configuration data containing the free-traffic domain name.
[0033] Specifically, after successfully obtaining the dedicated free-traffic domain name, the system enters the structured generation stage of policy configuration data. This involves converting and encapsulating the original domain name string into standard policy configuration data units that can be recognized, loaded, and executed by downstream system components or modules. The system creates a new configuration data object or data structure based on its internally defined policy data model. This policy configuration data includes the dedicated free-traffic domain name obtained in step 110, the identifier of the cooperating app that triggered this configuration generation, and configuration metadata indicating the effective status and scope of the configuration. During the generation process, the system formats and validates the free-traffic domain name according to a pre-set rule template to ensure it meets the specifications for subsequent technical processing and may add extended attributes such as expiration time and geographic attributes. The generated policy configuration data is a self-describing, machine-readable data entity. Its format can be JSON, XML, or a specific binary protocol format, designed for efficient parsing by the policy execution engine. This policy configuration data is not simply a domain name record, but a direct product and data representation of the network policy foundation supporting refined identification and statistics, providing a clear and executable instruction set for subsequent identification logic.
[0034] 130. The policy configuration data is applied to the processing of subsequent resource scheduling requests to enable domain name-based free traffic identification logic.
[0035] Specifically, the generated policy configuration data needs to be dynamically applied to the actual business processing pipeline to activate the domain name-based free-flow identification capability. The system distributes the policy configuration data generated in step 120 to all relevant processing nodes or service instances through the configuration management service or message bus. After receiving new or updated policy configuration data, the receiving node loads it into its own memory policy container or local cache. This loading process is usually accompanied by parsing, verifying and indexing the configuration data. For example, the free-flow domain name is used as the key, and the corresponding APP identifier and processing rule are used as the value to build an efficient memory hash mapping table to achieve fast query with O(1) time complexity. After the policy is successfully loaded, the corresponding processing node enables the free-flow identification logic based on this domain name. After that, when the processing logic of any resource scheduling request needs to determine whether it involves free-flow services, or when the domain name appears in the network traffic, the system can immediately identify the associated APP identity and the applicable free-flow rules by querying this loaded policy set. This process enables the dynamic binding of policies and business logic, ensuring the real-time and scalability of free-flow identification capabilities, and providing runtime decision support for the accurate execution of steps S200 and S300.
[0036] As an optional implementation of this application, optionally, in step S200, based on the resource scheduling request and scheduling result initiated by the APP, a resource access URL is generated and returned that replaces the target node IP address with the free-flow domain name, triggering subsequent network requests based on the domain name, including: 210. Based on the resource scheduling request sent by the APP client, receive and parse the request, and extract user context information, resource path and query parameters.
[0037] Specifically, when an app client needs to obtain a resource, it initiates a resource scheduling request to its pre-configured scheduling server endpoint. The system's network interface listening module first receives the HTTP or HTTPS request message at the application layer. Subsequently, the request parsing engine is triggered to perform structured parsing on the received raw request message. This process includes parsing the HTTP request line to obtain the method and the raw request URL, parsing HTTP header fields to extract key user context information, such as user identity tokens embedded in headers or cookies, device identifiers, client IP addresses, network types, and app version numbers. Simultaneously, the system separates and extracts the resource path and query parameters from the raw request URL in the request line. The resource path refers to the logical path of the target resource on the server, while the query parameters contain a set of key-value pairs used for resource location, authentication, or business customization. The parsed user context information serves as the input for subsequent intelligent node scheduling decisions, while the extracted resource path and query parameters are the core components constituting the final resource access address. By transforming unstructured network requests into structured data objects that the system can understand, containing business semantics and user state, the foundation for subsequent accurate scheduling and address construction is laid.
[0038] 220. Based on the parsed user context information, execute the node selection logic to determine a target node from the edge node cluster and obtain the IP address of the target node.
[0039] Specifically, after successfully parsing the request and extracting user context information, the system enters the edge node selection decision stage. The system uses the extracted user context information, such as the user's geographical location, current network operator, real-time network quality indicators, edge node load status, and session affinity requirements, as input parameters for the decision algorithm. Based on these parameters, the algorithm calculates and filters target nodes from a widely distributed edge node cluster that can provide the optimal service experience for the specific user in this request scenario. The optimal target node is typically the best choice after comprehensive evaluation of latency, bandwidth, cost, and load balancing. Once the target node is determined, the system immediately retrieves the node's network layer identifier, i.e., its IP address, from the node information database. This address may be in IPv4 or IPv6 format. This IP address represents the exact physical or logical location of the resource in the CDN network and is a key element in constructing the original resource access address. By implementing dynamic optimization routing for resource access, the system ensures that users are always guided to the most suitable service node. Simultaneously, the output target node IP address serves as the original coordinate reference for subsequent free-flow domain name replacement operations.
[0040] 230. Based on the IP address of the target node, the resource path and query parameters, and the exclusive free-flow domain name obtained for the APP, perform a URL rewriting operation to generate an access address that uses the free-flow domain name as the network location identifier and includes the resource path and query parameters.
[0041] Specifically, the core address translation operation, namely URL rewriting, is performed. Its inputs include: the target node IP address obtained in step 220, the resource path and query parameters extracted in step 210, and the dedicated free-traffic domain name obtained in step 110 and assigned to the current APP. The URL rewriting operation includes two ordered technical sub-actions: host identifier replacement and resource path concatenation. First, host identifier replacement is performed. Based on the target node's IP address, the system constructs an original access address prototype using the IP address as the network location identifier. Then, the system replaces the network location portion of the address prototype with the dedicated free-traffic domain name, generating an intermediate address. This replacement operation changes the destination of traffic from a specific CDN server IP to a dedicated domain name used for business identification. Second, resource path concatenation is performed. This resource path concatenation operation is a rigor guarantee, designed to ensure that after host identifier replacement, the complete resource path and query parameters extracted from the original request are appended to the new URL with the new domain name as the host without any changes and in the correct order. Through these two sub-operations, a standard, complete access address is finally generated, which uses the exclusive free-flow domain name as the network location identifier and contains all the original resource location information. This address will serve as a guiding beacon for the free-flow service, triggering subsequent network requests based on the domain name.
[0042] 240. Based on the generated access address, construct an HTTP response message and return it to the APP client, so that the APP client initiates a resource acquisition request based on the access address.
[0043] Specifically, the system constructs a standard HTTP success response message based on the final resource access URL generated in step 230. The construction process follows HTTP protocol specifications, with the status line set to 200 OK or 302 Found to indicate success. The response header includes necessary fields such as Content-Type and cache control headers, while the response body directly contains the generated resource access URL string. Subsequently, the system sends this HTTP success response message back to the APP client that initiated the resource scheduling request through the established request-response connection channel. Upon receiving this response, the client's built-in network library or business logic parses the response and extracts the access address. Since this address is a standard URL format, the client will treat it like any ordinary network address, initiating the subsequent actual resource acquisition request (usually an HTTPS GET request) based on this address (at this point, the host portion is a dedicated free-flow domain name). This achieves seamless integration from the scheduling result to the final download behavior, and the entire process is transparent to the APP client. The client does not need to be aware of the complex IP-to-domain conversion that occurs behind the scenes; it only needs to follow standard network protocol behavior.
[0044] As an optional implementation of this application, optionally, in step S300, based on the resource request carrying the dedicated free-traffic domain name and the established domain name binding relationship, the free-traffic policy is executed through the operator's free-traffic gateway, traffic is counted at the APP level and the request is routed to the CDN node, and the traffic is converted into a free-traffic service state, including: 310. Based on the secure connection request initiated by the APP client according to the access address, the operator's free data gateway intercepts the connection establishment process at the transport layer and extracts the target domain name from the server identifier field in the security protocol or the host field in the application layer protocol header.
[0045] Specifically, when an app client initiates an actual resource acquisition request based on the received access address (whose host portion is a dedicated free-traffic domain name), the request first reaches the operator's network. The free-traffic gateway, deployed on the critical path of the operator's network, uses deep packet inspection technology to intercept and monitor the connection establishment process in real time at the transport layer. For HTTPS requests, the gateway intervenes after the TCP connection is established and during the TLS handshake phase, parsing the Client Hello message and extracting the Server Name Indicator (SNI) field from the TLS extension field. This SNI field carries the target domain name the client intends to connect to in plaintext. For HTTP requests, the gateway parses the application layer's HTTP request header after the TCP connection is established, extracting the target domain name from the Host header field. Regardless of whether it uses the SNI or the Host field, the core operation performed by the gateway is to reliably extract the target domain name the client is trying to access from the standardized plaintext portion of the protocol. The extraction mechanism of the server identifier field or the host field in the application layer protocol header in this security protocol enables the gateway to accurately determine the domain name that the traffic intends to access without decrypting the user's encrypted business data (for HTTPS). This provides a unique and reliable input for subsequent free traffic policy matching, and achieves efficient and compliant preliminary feature extraction of massive encrypted or unencrypted traffic.
[0046] 320. Based on the extracted target domain name, the operator's free data gateway queries the locally loaded free data domain name binding policy library and performs a matching operation to obtain the corresponding APP identifier.
[0047] Specifically, after successfully extracting the target domain name from the network connection, the operator's free-data gateway immediately initiates a policy matching query process. The gateway maintains a locally loaded, resident memory-based free-data domain name binding policy library. This policy library is a synchronized image or subset of the network policy foundation built in steps 110 to 130 on the operator's side, and its data model also uses domain names as key indexes. The gateway uses the extracted target domain name as the query key to perform exact or longest prefix matching queries in this policy library. The query interface of the policy library aims to quickly return metadata associated with the domain name, the core of which is the corresponding APP identifier. If the query matches, the unique identifier of the cooperating APP represented by the domain name is successfully obtained; if it does not match, the traffic is treated as ordinary internet traffic and enters the regular forwarding process, without enjoying free-data treatment. This matching process essentially completes the conversion from network technology identifier to business identity identifier. The obtained APP identifier serves as the unified basis for the execution of all subsequent differentiated policies. It will be used to instruct the billing system, statistics system, etc., on what specific business rules should be applied to this data stream, ensuring the accuracy and business relevance of the free data policy execution and avoiding the misuse or abuse of the policy.
[0048] 330. Based on the APP identifier obtained through matching, the operator's free data gateway executes billing exemption and traffic statistics instructions on the network data stream corresponding to the connection.
[0049] Specifically, after successfully matching and obtaining the APP identifier, the operator's data-free gateway immediately performs substantive data-free service operations on the network data stream corresponding to the connection, namely, billing waiver and traffic statistics instructions. The execution of this instruction involves two parallel core processing threads or logic modules. The first module performs the billing waiver operation. Based on the matched APP identifier, the gateway adds a specific billing waiver flag to the protocol header or metadata of all eligible IP packets flowing through this connection. This flag is an identifier with special semantics in the operator's billing system. When the backend billing collection point detects a packet with this flag, it will exclude it from the user's regular traffic billing list, thereby achieving fee waiver. The second module performs the traffic statistics operation. The gateway also performs real-time byte counting on the same data stream based on the APP identifier, monitors the number of bytes of data stream passing through the gateway interface, and aggregates the accumulated value by the APP identifier dimension. Subsequently, the gateway periodically or at the end of the data flow updates the aggregated traffic data to an independent statistical storage unit separate from the user's individual bill. This unit is a statistical database customized for cooperative businesses, used to record the total free data consumed by each APP for business reconciliation, cost accounting and resource monitoring.
[0050] 340. After executing the billing exemption and traffic statistics instructions, the operator's free traffic gateway routes the resource acquisition request message to the destination CDN edge node.
[0051] Specifically, after completing the billing exemption marking and traffic statistics operations for the data stream, the operator's free-data gateway must also ensure that the user's resource acquisition request can be correctly delivered. The gateway retrieves the original resource acquisition request packet that was previously temporarily cached or directly passed through. This packet has not been tampered with during the gateway's protocol parsing and policy matching process, and its TCP / IP layer and above application layer content remain unchanged. Based on the destination IP address of the request packet or directly based on the previously parsed context, the gateway performs standard network layer routing and forwarding, routing this request packet through the operator's network to the destination CDN edge node, i.e., the service node where the resource is actually stored. For the client and CDN server, the gateway's intervention is transparent. A complete connection processed by the operator's policies is established between the client and the CDN server, allowing the resource to be downloaded normally. This ensures the integrity of the service function, making free-data processing a value-added service link in the network, rather than an interruption or interference link, ultimately realizing the seamless conversion of user traffic into a service state where resources can be successfully acquired while enjoying the free-data policy.
[0052] Example 2 As an application example of this application, the specific application is as follows: By shifting the identifier of the free data policy from "IP address" to "domain name," and dynamically replacing the Host portion when returning the resource URL through CDN scheduling services, while relying on the operator's gateway to identify, count, and enforce policies for requests carrying free data domain names, a transparent switch and capability upgrade of the free data mechanism is achieved while maintaining the original APP request process unchanged. The process is as follows: Figure 2 As shown.
[0053] I. Detailed Description of Implementation Examples The embodiment includes the following key modules and steps: Module 1: Pre-configuration and registration of free-traffic domain names In the CDN management platform, configure one or more dedicated free-flow domains for each cooperative service (such as "XX Video APP"). For example: primary free-flow domain: video.wo186.com.cn, backup free-flow domain: cdn-video.wo186.com.cn. This domain must meet the following conditions: An application for data-free service has been submitted to the target operator (such as XX operator) and successfully included in its data-free service policy library; ICP filing has been completed (if applicable); A valid SSL / TLS certificate has been deployed (supports RSA / ECC and is compatible with mainstream Android / iOS versions). The DNS resolution record (A / AAAA) points to the CDN edge node cluster; CDN edge nodes can be configured with domain name acceleration channels to correctly route to the corresponding business backend based on the Host header. Key addition: This domain name is bound to the AppID, Bundle ID, or Package Name of the partner app in the operator's system for subsequent traffic aggregation.
[0054] Module 2: CDN Scheduling Service Transformation After receiving the original request from the APP, the CDN scheduling service (usually an HTTP API) executes the following logic: Parse the request context: obtain user ID, device information, carrier affiliation, requested resource path, etc.; Send a request to the CDN management platform to obtain the corresponding free-flow domain name based on the AppID; Perform normal scheduling logic: Select the optimal edge node (IP: 203.0.113.45); Generates URLs in domain name format (core innovation): Instead of constructing http: / / 203.0.113.45 / test / test.flv, it constructs http: / / video.wo186.com.cn / test / test.flv; retaining the original path, query parameters, token, etc. A 200 response is returned: the response body contains the domain URL, in the following format: {"code":200,"url":"https: / / video.wo186.com.cn / test / test.flv?token=abc123&expires=1700000"} Module 3: Collaboration with Carrier-Free Data Gateways Operators deploy "intelligent data-free gateways" (such as XX operator's CDN gateway system) in their core network. These gateways have the following capabilities: Domain name identification: Using DPI or UPF strategies, identify whether the Host header or SNI field in the HTTP / HTTPS request matches the pre-registered free-traffic domain name; APP binding mapping: Determine the ownership of this traffic based on the domain name → APP binding relationship; Free-of-charge flag: Marks matching requests as free-of-charge, without deducting general traffic; Detailed statistics: Data usage is recorded by app (e.g., XX Video - Free data: 125MB); Data synchronization: Synchronize the statistical results to the operator's billing and user service platform (such as the XX operator's APP backend). Module 4: Seamless Switching on the User End After receiving the domain URL, the app initiates a request according to the standard HTTP protocol; The request is routed through the user equipment → base station → core network → free data gateway; The gateway identifies the host: video.wo186.com.cn, and performs free data usage and statistics. The request is forwarded to the CDN edge node (IP remains 203.0.113.45). Edge nodes identify services through the Host header and return resources; The app plays normally, and the user is completely unaware of the process.
[0055] Module 5: Canary Deployment and Rollback Mechanism To ensure stability, the following capabilities are supported: Proportional grayscale implementation: Return the domain URL to 10% of users, while still returning the IP URL to 90%; Based on regional grayscale: first pilot the program in a certain province; Gray-scale rollout by APP version: Domain data exemption is only enabled for new APP versions; Second-level rollback: If monitoring detects an anomaly (such as an increase in 4xx / 5xx), immediately switch back to IP mode.
[0056] Module Six: End-to-End HTTPS Support The scheduling service returns an HTTPS domain URL; End-to-end TLS encryption between the app and edge nodes; Carrier gateways support SNI resolution to ensure accurate identification of HTTPS data-free services; It complies with GDPR, cybersecurity level protection and other compliance requirements.
[0057] II. Specific Implementation background: The XX Video app originally used IP-based data-free streaming, with CDN dispatch returning URLs like http: / / 203.0.113.45 / v / 123.mp4. Users could not see the details in the XX operator's app. It needs to be upgraded to domain-based data-free streaming.
[0058] Implementation steps: Preliminary preparations: XX Video applied to XX operator for a data-free domain name: mangguo.wo186.com.cn; The XX operator registered this domain name in the free data gateway system and bound it to the Mango APP; The operator synchronizes this binding relationship to the user service platform and distributes it to the operator's gateway system; XX Video has configured the "free-flow domain" on the CDN platform as mangguo.wo186.com.cn; Deploy a wildcard SSL certificate for mangguo.wo186.com.cn.
[0059] User request process: When a user clicks to play a video, the app sends a request: GET / api / get_url? Vid=123 HTTP / 1.1 CDN scheduling service returned: { "url": "https: / / mangguo.wo186.com.cn / v / 123.mp4?token=xyz"} The app sends a request to mangguo.wo186.com.cn; Requesting access to the XX operator's data-free gateway; The gateway identifies the domain name, matches the APP as "XX Video", marks it as free data, and adds 300MB of data usage. Data is synchronized to the XX operator's APP backend; Users can open the "XX Carrier App" → "Data Usage" → and see: "XX Video: 300MB free data usage".
[0060] The edge node returned the video, and playback was successful.
[0061] Monitoring and optimization: CDN monitoring domain URL success rate; XX operator's monitoring gateway identification accuracy; If the DNS in a certain area is abnormal, you can temporarily switch back to IP mode; Gradually switch to full capacity.
[0062] Example 3 Based on the same principle as the aforementioned method, a CDN-based device for switching from IP-based free traffic to domain-based free traffic is also proposed, see [link to relevant documentation]. Figure 3 An embodiment of this disclosure provides a CDN-based device 100 for switching from IP-based free traffic to domain-based free traffic, comprising: The free data policy basic construction module 110 is used to obtain exclusive free data domains from the established domain name binding relationship based on the free data requirements of cooperative APPs, and build a network policy foundation that supports fine-grained identification and statistics. The free access address generation module 120 is used to generate and return a resource access URL that replaces the target node IP address with the free domain name based on the resource scheduling request and scheduling result initiated by the APP, and trigger subsequent network requests based on the domain name. The free-traffic policy execution and traffic statistics module 130 is used to execute the free-traffic policy through the operator's free-traffic gateway based on the resource request carrying the exclusive free-traffic domain name and the established domain name binding relationship, to count traffic by APP dimension and route the request to CDN node, and to convert the traffic into a free-traffic service state.
[0063] As an optional implementation of this application, the data-free access address generation module 120 may further include: The scheduling decision and IP acquisition module 121 is used to parse and extract the scheduling context based on the resource scheduling request sent by the APP client, execute the node selection algorithm to determine the target node and obtain its IP address; The free-flow domain name replacement URL generation module 122 is used to perform host identifier replacement and path concatenation based on the target node IP address, resource path and query parameters, and exclusive free-flow domain name to generate an access address with the free-flow domain name as the network location identifier. The transparent response triggering module 123 is used to encapsulate the generated free access address into a standard HTTP response and return it to the APP client to trigger subsequent free resource requests based on the domain name.
[0064] Obviously, those skilled in the art should understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the control methods described above. The modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Therefore, this application is not limited to any specific hardware and software combination.
[0065] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the control methods described above. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.
[0066] Example 4 Furthermore, this application proposes an electronic device for implementing any of the aforementioned CDN-based methods for switching from IP-based free traffic to domain-based free traffic, comprising: The processor is used to execute the complete process of obtaining a dedicated free-flow domain name from the established domain name binding relationship to build the network policy foundation based on the free-flow request of the cooperative APP, generating and returning a resource access URL that replaces the target node IP address with the free-flow domain name according to the resource scheduling request initiated by the APP, and executing the free-flow policy through the operator's free-flow gateway according to the resource request carrying the dedicated free-flow domain name, and statistically analyzing traffic by APP dimension and routing the request to CDN node, thereby converting the traffic into a free-flow service state. The storage device is used to store established domain name binding relationships, free data access addresses generated for apps, matched app identifiers, and free data usage data statistically analyzed by app dimension.
[0067] The electronic device of this disclosure includes a processor and a memory for storing processor-executable instructions. The processor is configured to execute the executable instructions to implement any of the preceding CDN-based methods for switching from IP-based free-flow to domain-based free-flow.
[0068] It should be noted that the number of processors can be one or more. Furthermore, the electronic device in this embodiment may also include input devices and output devices. The processor, memory, input devices, and output devices can be connected via a bus or other means, without specific limitations herein.
[0069] The memory can be used to store computer executable programs and various configurations, such as the program corresponding to the CDN-based method for converting from IP-based free traffic to domain-based free traffic in this embodiment of the present disclosure. The processor loads and runs the software program in the memory, thereby executing various functional applications and data processing of the electronic device.
[0070] Input devices can be used to receive input digital numbers or signals. These signals can be key signals related to user settings and function control of the device / terminal / server. Output devices can include display devices such as screens.
[0071] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.
Claims
1. A method for switching from IP-based free traffic to domain-based free traffic based on CDN, characterized in that, include: Based on the data-free requirements of partner apps, exclusive data-free domains are obtained from the established domain name binding relationships to build a network strategy foundation that supports fine-grained identification and statistics; Based on the resource scheduling request and scheduling result initiated by the APP, a resource access URL is generated and returned that replaces the target node IP address with the free-flow domain name, triggering subsequent network requests based on the domain name; Based on the resource request carrying the dedicated free-flow domain name and the established domain name binding relationship, the free-flow policy is executed through the operator's free-flow gateway, traffic is counted at the APP level and the request is routed to the CDN node, and the traffic is converted into a free-flow service state.
2. The method for switching from IP-based free traffic to domain-based free traffic based on CDN as described in claim 1, characterized in that, The aforementioned free data usage requirement based on partner apps involves obtaining dedicated free data usage domains from established domain name binding relationships to build a network policy foundation that supports refined identification and statistics, including: Based on the identifier of the cooperating APP, a query request is initiated to the established domain name binding relationship to obtain the exclusive free-traffic domain name bound to the APP; Based on the obtained dedicated free-traffic domain name, generate policy configuration data containing the free-traffic domain name; The policy configuration data is applied to the processing of subsequent resource scheduling requests to enable domain-based free traffic identification logic.
3. The method for switching from IP-based free traffic to domain-based free traffic based on CDN as described in claim 1, characterized in that, The step of generating and returning a resource access URL that replaces the target node's IP address with the free-traffic domain name based on the resource scheduling request and scheduling result initiated by the APP, and triggering subsequent network requests based on the domain name, includes: Based on the resource scheduling request sent by the APP client, receive and parse the request, and extract user context information, resource path and query parameters; Based on the parsed user context information, the node selection logic is executed to determine a target node from the edge node cluster and obtain the IP address of the target node; Based on the IP address of the target node, the resource path and query parameters, and the exclusive free-flow domain name obtained for the APP, a URL rewriting operation is performed to generate an access address that uses the free-flow domain name as the network location identifier and includes the resource path and query parameters. Based on the generated access address, an HTTP response message is constructed and returned to the APP client, causing the APP client to initiate a resource acquisition request based on the access address.
4. The method for switching from IP-based free traffic to domain-based free traffic based on CDN as described in claim 1, characterized in that, The step of executing the free-traffic policy through the operator's free-traffic gateway based on the resource request carrying the dedicated free-traffic domain name and the established domain name binding relationship, counting traffic by APP dimension and routing the request to CDN nodes, and converting the traffic into a free-traffic service state includes: Based on the secure connection request initiated by the APP client according to the access address, the operator's free data gateway intercepts the connection establishment process at the transport layer and extracts the target domain name from the server identifier field in the security protocol or the host field in the application layer protocol header. Based on the extracted target domain name, the operator's free data gateway queries the locally loaded free data domain name binding policy library and performs a matching operation to obtain the corresponding APP identifier; Based on the APP identifier obtained through matching, the operator's free data gateway executes billing exemption and traffic statistics instructions on the network data stream corresponding to the connection; After executing the billing exemption and traffic statistics instructions, the operator's free traffic gateway routes the resource acquisition request message to the destination CDN edge node.
5. The method for switching from IP-based free traffic to domain-based free traffic based on CDN as described in claim 3, characterized in that, The step of performing a URL rewriting operation based on the IP address of the target node, the resource path, the query parameters, and the dedicated free-data domain name obtained for the APP, to generate an access address that uses the free-data domain name as the network location identifier and includes the resource path and query parameters, includes: Based on the IP address of the target node and the dedicated free-traffic domain name, perform host identifier replacement, replacing the network location portion in the original access address based on the IP address with the free-traffic domain name; Based on the resource path and query parameters, perform resource path concatenation, appending the complete resource path and query parameters to the address with the free-flow domain name as the network location identifier, to form the final resource access URL.
6. The method for switching from IP-based free traffic to domain-based free traffic based on CDN as described in claim 3, characterized in that, The step of constructing an HTTP response message based on the generated access address and returning it to the APP client, so that the APP client initiates a resource acquisition request based on the access address, includes: Based on the generated resource access URL, it is used as the response body content, encapsulated into a standard HTTP success response message, and the HTTP success response message is sent to the APP client.
7. The method for switching from IP-based free traffic to domain-based free traffic based on CDN as described in claim 4, characterized in that, The step of executing billing exemption and traffic statistics instructions on the network data stream corresponding to the connection by the operator's free data gateway based on the APP identifier obtained through matching includes: Based on the APP identifier obtained through matching, a free-of-charge flag is added to the data packets corresponding to the connection; Based on the APP identifier and the real-time byte count of the data flow through the gateway, the traffic data is updated to the independent statistical storage unit according to the APP to which it belongs.
8. A device for converting from IP-based free-traffic to domain-based free-traffic based on CDN, the device comprising: The free data policy basic construction module is used to obtain exclusive free data domains from the established domain name binding relationship based on the free data requirements of cooperative apps, and build a network policy foundation that supports fine-grained identification and statistics. The free-data access address generation module is used to generate and return a resource access URL that replaces the target node IP address with the free-data domain name based on the resource scheduling request and scheduling result initiated by the APP, and trigger subsequent network requests based on the domain name; The free-traffic policy execution and traffic statistics module is used to execute the free-traffic policy through the operator's free-traffic gateway based on the resource request carrying the exclusive free-traffic domain name and the established domain name binding relationship, to count traffic by APP dimension and route the request to CDN node, and to convert the traffic into a free-traffic service state.
9. The device for converting from IP-based free access to domain-based free access based on CDN according to claim 8, wherein the free access address generation module further comprises: The scheduling decision and IP acquisition module is used to parse and extract the scheduling context based on the resource scheduling request sent by the APP client, execute the node selection algorithm to determine the target node and obtain its IP address; The free-flow domain name replacement URL generation module is used to perform host identifier replacement and path concatenation based on the target node IP address, resource path and query parameters, and exclusive free-flow domain name to generate an access address with the free-flow domain name as the network location identifier; The transparent response triggering module is used to encapsulate the generated free access address into a standard HTTP response and return it to the APP client to trigger subsequent free resource requests based on the domain name.
10. An electronic device for implementing the CDN-based method for switching from IP-based free traffic to domain-based free traffic as described in any one of claims 1 to 7, comprising: The processor is used to execute the complete process of obtaining a dedicated free-flow domain name from the established domain name binding relationship to build the network policy foundation based on the free-flow request of the cooperative APP, generating and returning a resource access URL that replaces the target node IP address with the free-flow domain name according to the resource scheduling request initiated by the APP, and executing the free-flow policy through the operator's free-flow gateway according to the resource request carrying the dedicated free-flow domain name, and statistically analyzing traffic by APP dimension and routing the request to CDN node, thereby converting the traffic into a free-flow service state. The storage device is used to store established domain name binding relationships, free data access addresses generated for apps, matched app identifiers, and free data usage data statistically analyzed by app dimension.