HK1218214B - Methods and systems for dynamic spectrum arbitrage user profile management - Google Patents

Description

Method and system for dynamic spectrum arbitrage user profile management

RELATED APPLICATIONS

This application claims benefit of priority from U.S. provisional application No. 61/828,335 entitled "Methods and Systems for dynamic spectrum allocation User Profile Management," filed on 29/5/2013, the entire contents of which are incorporated herein by reference.

Background

With the ever-increasing use of wireless communication devices for accessing networks and downloading large files (e.g., video files), there is an increasing demand for radio spectrum. Smart phone users complain of dropped calls, slow access to the internet, and similar problems, largely due to the large number of devices attempting to access the limited RF bandwidth allocated to such devices. However, due to the discontinuity of such voice radio communication bands and the use of episodics, certain portions of the RF spectrum, such as the RF bands dedicated to emergency services (e.g., police, fire and rescue, etc.), are largely idle. Accordingly, an improved method and system for dynamically allocating underutilized telecommunications resources (e.g., RF spectrum, etc.) of a first telecommunications network for access and use by wireless devices subscribing to other networks would be beneficial to telecommunications networks, service providers, and consumers of telecommunications services.

Disclosure of Invention

Various embodiments include a Dynamic Spectrum Arbitrage (DSA) system comprising: a Home Subscriber Server (HSS) having an HSS processor; a Mobility Management Entity (MME) having an MME processor coupled to the HSS via a first communication link; an eNodeB having an eNodeB processor coupled to the MME via a second communication link; a Dynamic Spectrum Controller (DSC) having a DSC processor coupled to the eNodeB via a third communication link; and a dynamic spectrum policy controller (DPC) having a DPC processor coupled to the DSC via a fourth communication link.

In one embodiment, the HSS processor may be configured with processor-executable instructions to perform operations comprising: determining whether HSS information (e.g., HSS subscriber profile information) stored in a memory of the HSS has changed for the wireless device; in response to determining that the HSS information has changed, determining whether the changes affect user profile information stored in a user profile repository of the MME; generating a changed data communication message including information identifying the changes; and sending the generated altered data communication message to the MME via the first communication link.

In a further embodiment, the MME processor may be configured with processor-executable instructions to perform operations comprising: receiving the altered data communication message via the first communication link; and adding user profile information included in the received changed data communication message to the user profile repository. In a further embodiment, the MME processor may be configured with processor-executable instructions to perform operations comprising: receiving the altered data communication message via the first communication link; and modifying the user profile information stored in the user profile repository using information included in the received changed data communication message.

In a further embodiment, the MME processor may be configured with processor-executable instructions to perform operations comprising: receiving the altered data communication message via the first communication link; determining whether a Public Data Network (PDN) subscription context has an associated active PDN connection in the MME using information included in the received changed data communication message; determining whether a subscription quality of service (QoS) profile has been modified; and performing a subscription QoS modification operation in response to determining that the subscription QoS profile has been modified.

In a further embodiment, the MME processor may be configured with processor-executable instructions to perform operations comprising: determining whether subscription data and mobility management context of a disconnected wireless device have been deleted; and sending a clear communication message to the HSS via the first communication link in response to determining that the subscription data and the mobility management context of the disconnected wireless device have been deleted.

In a further embodiment, the HSS processor may be configured with processor-executable instructions to perform operations comprising: receiving the clear communication message via the first communication link; and setting a clear flag in response to receiving the clear communication message.

In a further embodiment, the DPC processor may be configured with processor-executable instructions to perform operations including: receiving a resource withdrawal communication message from the second DSC indicating that resources submitted for the auction should be withdrawn from the auction; and sending the received resource withdrawal communication message to the DSC via the fourth communication link.

In a further embodiment, the DSC processor may be configured with processor-executable instructions to perform operations comprising: receiving the resource withdrawal communication message from the DPC via the fourth communication link; and sending a request to delete the closed subscriber group identifier associated with the revoked resource to the eNodeB via the third communication link.

In a further embodiment, the eNodeB processor may be configured with processor-executable instructions to perform operations comprising: receiving the request to delete the closed subscriber group identifier from the DSC via the third communication link; updating the active resource list by removing the closed subscriber group identifier from the active resource list; generating a configuration update communication message, the configuration update communication message including the updated list of active resources; and sending the configuration update communication message to the MME via the second communication link.

In a further embodiment, the DSC processor may be coupled to the HSS via a fifth communication link, and the DSC processor may be coupled to the MME via a sixth communication link. In a further embodiment, the HSS processor may be configured with processor-executable instructions to perform operations comprising: receiving updated HSS information from the DSC via the fifth communication link; determining whether the updated HSS information affects user profile information stored in a user profile repository of the MME; generating a changed data communication message including information identifying the changes; and sending the generated altered data communication message to the MME via the first communication link.

Further embodiments include a Dynamic Spectrum Arbitrage (DSA) method of synchronizing information, which may include: determining, in a processor of a Home Subscriber Server (HSS), whether HSS information stored in a memory of the HSS has changed for a wireless device; in response to determining that the HSS information has changed, determining whether the changes affect user profile information stored in a user profile repository of a Mobility Management Entity (MME); generating a changed data communication message including information identifying the changes; and sending the generated changed data communication message to the MME.

In one embodiment, the method may comprise: receiving the changed data communication message in an MME processor of the MME; and adding user profile information included in the received changed data communication message to the user profile repository of the MME. In a further embodiment, the method may comprise: receiving the changed data communication message in an MME processor of the MME; and modifying user profile information stored in the user profile repository of the MME using information included in the received changed data communication message. In a further embodiment, the method may comprise: receiving the changed data communication message in an MME processor of the MME; determining whether a Public Data Network (PDN) subscription context has an associated active PDN connection in the MME using information included in the received changed data communication message; the MME processor determining whether a subscription quality of service (QoS) profile has been modified; and in response to determining that the subscription QoS profile has been modified, the MME processor performs a subscription QoS modification operation.

Further embodiments include a Home Subscriber Server (HSS) comprising a memory and a processor coupled to the memory and configured with processor-executable instructions to perform operations comprising: establishing a first communication link to a Mobility Management Entity (MME) server; determining whether HSS information stored in the memory has changed for the wireless device; in response to determining that the HSS information has changed, determining whether the changes affect user profile information stored in a user profile repository of a Mobility Management Entity (MME); generating a changed data communication message including information identifying the changes; and sending the generated altered data communication message to the MME via the first communication link. In a further embodiment, the HSS processor may be configured with processor-executable instructions to perform operations further comprising: establishing a second communication link to a Dynamic Spectrum Controller (DSC) server; receiving a user subscriber information request from the DSC via the second communication link; and sending the HSS information to the DSC in response to receiving the request. In a further embodiment, the HSS processor may be configured with processor-executable instructions to perform operations such that generating the changed data communication message comprises generating the changed data communication message to include information for determining whether a Public Data Network (PDN) subscription context has an associated active PDN connection in the MME. In a further embodiment, the HSS processor may be configured with processor-executable instructions to perform operations such that generating the varied data communication message comprises generating the varied data communication message to include information for determining whether a subscription quality of service (QoS) profile has been modified for the wireless device.

Further embodiments include a computing device having a processor (or processing core) configured with processor-executable instructions to perform operations corresponding to those operations/methods discussed above.

Further embodiments include a plurality of computing devices including various means for performing functions corresponding to those operations/methods discussed above.

Further embodiments include a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor/processing core to perform operations corresponding to those operations/methods discussed above.

Drawings

The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate exemplary embodiments of the invention and, together with the general description given above and the detailed description given below, serve to explain the features of the invention.

Fig. 1A through 1E are system block diagrams illustrating various logical and functional components and communication links in a plurality of communication systems that may be used to implement various embodiments.

Fig. 2A is a process flow diagram illustrating a Dynamic Spectrum Arbitration (DSA) method of allocating resources from the perspective of a dynamic spectrum policy controller (DPC) according to one embodiment.

Figure 2B is a message flow diagram illustrating the communication of messages between components of the DSA communication system when allocating resources according to one embodiment.

Fig. 3 through 7 are process flow diagrams illustrating an embodiment DSA method for allocating and accessing resources in a communication system including one DPC, two Dynamic Spectrum Controllers (DSCs), and one wireless device.

Fig. 8A-8C are message flow diagrams illustrating an embodiment Dynamic Spectrum Arbitration Application Part (DSAAP) registration method.

Fig. 9A and 9B are message flow diagrams illustrating an embodiment DSAAP advertising method.

Fig. 10A and 10B are message flow diagrams illustrating an embodiment DSAAP method for communicating a list of available resources.

Fig. 11A and 11B are message flow diagrams illustrating a DSAAP bidding method according to an embodiment.

Fig. 12A to 12D are message flow diagrams illustrating a DSAAP notification method of an embodiment for notifying results of those bidding operations for a plurality of participating networks.

Fig. 13A and 13B are message flow diagrams illustrating an embodiment DSAAP purchase method for instantly (or nearly instantly) purchasing resources.

Fig. 14A and 14B are message flow diagrams illustrating an embodiment DSAAP allocation method for allocating resources in a lessor network for access and use by multiple components in the lessee network.

Fig. 15A and 15B are message flow diagrams illustrating an embodiment DSAAP back-off method of selectively switching a wireless device from a lessor network back to a lessee's network (i.e., its home PLMN).

Fig. 16A is a message flow diagram illustrating a DSC-initiated DSAAP deregistration method of an embodiment for terminating DSA operations.

Fig. 16B is a message flow diagram illustrating a DPC-initiated DSAAP deregistration method of an embodiment for terminating DSA operations.

Fig. 17A is a message flow diagram illustrating a DSC-initiated DSAAP error indication method for reporting errors.

Fig. 17B is a message flow diagram illustrating a DPC initiated DSAAP error indication method for reporting errors.

FIGS. 18A and 18B are message flow diagrams illustrating an embodiment user profile management method.

Fig. 18C is a message flow diagram illustrating an embodiment DSC method to request subscriber data from a Home Subscriber Server (HSS).

Fig. 19 is a process flow diagram illustrating an embodiment HSS method to update user profile information in a Mobility Management Entity (MME).

Fig. 20 is a process flow diagram illustrating an embodiment MME method of updating user profile information and modifying a quality of service (QoS) level of a wireless device based on the updated user profile information.

Fig. 21 is a component block diagram of an example wireless device suitable for use with the various embodiments.

FIG. 22 is a component block diagram of a server suitable for use with one embodiment.

Detailed Description

Embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References to specific examples and implementations are for illustrative purposes, and are not intended to limit the scope of the invention or the claims.

As used herein, the terms "mobile device," "wireless device," and "User Equipment (UE)" are used interchangeably and refer to a variety of cellular telephones, Personal Data Assistants (PDAs), palm-top computers, notebook computers with wireless modems, wireless electronic mail receivers (e.g., blackberries (blackberries)Anddevice), multimedia internet enabled cellular telephone (e.g.) And similar personal electronic devices. The wireless device may include a programmable processor and memory. In a preferred embodiment, the wireless device is a cellular handset (e.g., wireless device) that can communicate via a cellular telephone communications network.

As used in this application, the terms "component," "module," "engine," "manager" are intended to include a computer-related entity, such as but not limited to hardware, firmware, a combination of hardware and software, or software in execution, which is configured to perform a particular operation or function. For example, a component may be, but is not limited to being, a process running on a processor, an object, an executable, a thread of execution, a program, a computer, a server, network hardware, and the like. By way of illustration, both an application running on a computing device and the computing device can be referred to as a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one processor or core and/or distributed between two or more processors or cores. In addition, these components can execute from various non-transitory computer readable media having various instructions and/or data structures stored thereon.

A number of different cellular and mobile communication services and standards are available or contemplated in the future, all of which may be implemented and benefit from various embodiments. Such services and standards include, for example, third generation partnership project (3GPP), Long Term Evolution (LTE) systems, third generation wireless mobile communication technology (3G), fourth generation wireless mobile communication technology (4G), Global System for Mobile communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA2000TM), enhanced data rates for GSM evolution (EDGE), Advanced Mobile Phone System (AMPS), digital AMPS (IS-136/TDMA), evolution data optimized (EV-DO), Digital Enhanced Cordless Telecommunications (DECT), Worldwide Interoperability for Microwave Access (WiMAX), Wireless Local Area Network (WLAN), Public Switched Telephone Network (PSTN), Wi-Fi protected Access I&II(WPA、WPA2)、Integrated digital enhanced network (iden), Land Mobile Radio (LMR), and evolved universal terrestrial radio access network (E-UTRAN). Each of these techniques involves, for example, the transmission and reception of voice messages, data messages, signaling messages, and/or content messages. It should be understood that any reference to terminology and/or technical details relating to a separate telecommunications standard or technology is for illustrative purposes only and is not intended to limit the scope of the claims to a particular communication system or technology unless specifically recited in the claim language.

A high priority in response to any emergency or disaster situation is to establish effective communication. In a large-scale emergency or disaster (both man-made and natural) situation, it is important to maintain communication between all first responders and emergency personnel in order to effectively respond to, manage and control the emergency. In the absence of effective communication between the first responder and other emergency personnel, the resource may not be effectively moved to the area where it is most needed. Even in light emergency situations (e.g., traffic accidents and fires), the first responder must be able to call on support assets and coordinate with other services (e.g., public facilities, hospitals, etc.).

Ownership and use of ubiquitous wireless devices, emergency communication via wireless devices using commercial cellular mobile communications networks is often the most efficient and effective means of mobilizing emergency response personnel and resources. Enabling wireless devices to provide effective emergency communication avoids the technical challenges and costs of coordinating radio frequencies among various first responder agencies (e.g., police, fire, ambulance, FEMA, public facilities, etc.). Further, a first responder (e.g., a doctor, nurse, retired police, or military personnel) that is not on duty or is not typically equipped with a radio will have a wireless device or can be promptly lent to a wireless device.

However, emergency communication over cellular communication networks is not without problems. Cellular and other telecommunications networks ("networks") are designed to accommodate access requests from only a subset of the total number of wireless devices in a particular cell. In an emergency or crisis, network resources can become overburdened when predictable human responses to the situation prompt a large number of wireless device users within a particular cell to access the network simultaneously. A wireless device user may be attempting to alert emergency personnel of an emergency situation (such as a 911 emergency call) or alert friends or family members that the user is safe while in the area of the emergency situation. Some users may be transmitting images of emergency situations (fire, accident, etc.) to news services or friends. In a large scale situation, emergency responders using wireless devices for emergency communication will increase the volume of calls. In any event, the predictable increase in call volume during an emergency situation can overwhelm commercial cellular communication networks, particularly in the cell areas surrounding the emergency situation, thus making the networks unreliable for emergency response personnel communication use.

To overcome these and other limitations of existing solutions, various embodiments include a plurality of components configured to provide a hierarchical priority access (TPA) capability to a first responder to communicate quality of service (QoS) and grade of service (GoS) -based wireless device communications. A detailed description of an example TPA system is provided in U.S. patent No. 8,275,349, dated 2102, 9, 25, the entire contents of which are incorporated herein by reference in their entirety and for all purposes.

In general, a TPA system or solution may include various components configured to perform various TPA operations to coordinate, make available, and/or provide wireless communication resources to high priority users (e.g., emergency personnel) during times of high congestion or in emergency situations. For example, the plurality of TPA components may be configured to monitor the wireless network for call volume, determine whether the wireless network call volume exceeds a first predetermined threshold, partition wireless network resources based on priority when the wireless network call volume exceeds the first predetermined threshold, and reserve a portion of the partitioned resources for high priority use (i.e., for use by wireless devices of authorized emergency personnel). The TPA components may be further configured to monitor incoming and outgoing calls to determine whether to make a call from or to a high priority device (e.g., to or from one or more pre-registered wireless devices of authorized emergency personnel), allow general access to wireless network resources for as long as there is no call from or to the high priority device, and restrict general access to the wireless network resources in response to determining to make a call to or from the high priority device. Thus, TPA solutions allow telecommunications systems to make more use of available resources and ensure that high priority users can access and use the system when needed.

In various embodiments, these and other TPA operations may be performed in (or in conjunction with) a Dynamic Spectrum Arbitrage (DSA) system configured to dynamically manage the availability, allocation, access, and use of telecommunications resources (e.g., RF spectrum, etc.) between two or more networks (e.g., between a lessor network and a tenant network). A detailed description of an example DSA system is provided in U.S. patent No. 8,711,721, dated 4-29 of 2014, which is incorporated herein by reference in its entirety and for all purposes.

Briefly, a DSA system may include a dynamic spectrum policy controller (DPC) configured to manage DSA operations and interactions between two or more networks (e.g., between a lessor network and a tenant network). The DPC may communicate with various network components in the network provider network, either directly or through one or more Dynamic Spectrum Controller (DSC) components. For example, the DPC may communicate with a Home Subscriber Server (HSS), either directly or via DSC. The HSS may be the primary user database that stores/includes subscription-related information (i.e., subscription profiles, user profiles, etc.) as well as information about the location of subscribers and IP information. That is, the HSS may store subscription information for each wireless device, such as a subscription QoS profile, access restrictions for roaming, and the like. In addition, the HSS may store information about those Packet Data Networks (PDNs) to which the wireless device is allowed to connect. For example, the HSS may store an Access Point Name (APN) or PDN address indicating one or more subscribed IP addresses. The HSS may also store dynamic subscription information, such as an identification of a Mobility Management Entity (MME) to which the wireless device is currently attached or registered. The MME component and HSS component are discussed in further detail below.

As part of DSA-TPA operation, the DPC may communicate with the HSS components to determine the priority and access rights of the wireless devices. The DPC may also update information stored/maintained by the HSS component, which may result in the HSS component and the MME component storing inconsistent, conflicting, or contradictory information. As a result, DSA systems may not be able to provide appropriate services, particularly when the DSA operations are based on multiple layers of and/or select subsets for the subscribers.

To overcome these and other limitations, various embodiments include DSA components configured to communicate and perform DSA-HSS user profile management operations to dynamically add, remove, and modify subscriber information and profiles in order to allow the HSS and MME components to automatically synchronize their information storage and operation. This allows DSA systems to better provide DSA services based on multiple layers of and/or a selected subset for these subscribers.

In one embodiment, the HSS component may be configured to detect changes to HSS subscription information (e.g., user profile information) and determine whether the changes affect information managed/stored by the MME component. When the HSS determines that these detected changes affect the information managed/stored by the MME component, the HSS may communicate these changes to the MME component. In various embodiments, the HSS may communicate these changes via changed data communication messages or "insert subscriber data" communication messages.

The MME component may be configured to receive communication messages identifying these changes to subscription information (e.g., HSS information) and use the information included in these received messages to add, remove, or modify stored subscription information or user profile information of the MME. The MME component may then communicate these updates, additions or changes to the HSS component. These operations allow the HSS component and the MME component to automatically synchronize their databases, information stores, and operations, which is particularly important when allocating resources based on multiple layers of these subscribers and/or for a select subset of these subscribers.

Further, in response to these detected changes, the MME component may be configured to perform various additional operations in order to initiate appropriate actions. For example, in one embodiment, in response to receiving a communication message identifying those changes to the subscription information (e.g., HSS information), the MME component may be configured to determine whether to allow the wireless device to roam in its current network. In response to determining that the wireless device is not allowed to roam in the current network, the MME component may be further configured to initiate a disconnect procedure.

As another example, the MME component may be configured to determine whether a received Public Data Network (PDN) subscription context has an associated active PDN connection in the MME, determine whether a subscription QoS profile has been modified, determine whether the wireless device is in one of an ECM-connected state or an ECM-idle state, and determine whether an idle state signaling reduction (ISR) function has been activated for the wireless device. In response to determining that the subscription QoS profile has been modified, the wireless device is in one of an ECM-connected state or an ECM-idle state, and/or the ISR has not been activated, the MME component may be further configured to initiate (or cause the HSS component to initiate) a subscription QoS modification procedure/method. In a further embodiment, in response to determining that the wireless device is in the ECM-idle state and the ISR has been activated, the MME component may be configured to initiate (or cause the HSS component to initiate) the subscription QoS modification procedure/method after the next ECM-idle-to-ECM-connection transition.

As discussed in further detail below, in one embodiment, in response to the lessor DSC determining that resources submitted for the auction should be revoked (e.g., for administrative reasons), the lessor DSC may be configured to send a resource revocation message to the DPC. The DPC may receive the resource withdraw message and notify the tenant of the DSC resource withdraw. The tenant DSC may delete the particular CSG id associated with the revoked resource from all affected enodebs in the tenant network (i.e., which are managed by the tenant DSC). This may trigger an eNodeB in the tenant network to send a configuration update message to the tenant MME along with the current list of CSG ids supported (where the CSG ids associated with the revoked resources no longer exist). Further, the DPC may notify the HSS that the CSG id associated with the revoked resource has been removed. In response to receiving notification of a CSG membership change for a tenant wireless device, the HSS may be configured to send a changed data communication message or an "insert subscriber data" message to those MMEs in the tenant network or the lessor network.

Various embodiments may include a DSA system comprising a HSS component, an MME component, an eNodeB, a DSC, and a DPC. The DPC may be coupled to the DSC, which may be coupled to the eNodeB. The eNodeB may be coupled to the MME, which may be coupled to the HSS. Further, in various embodiments, the DSC and/or DPC may be coupled to the HSS and/or MME.

The HSS may be configured to determine whether subscription information (or HSS information) stored in a memory of the HSS has changed for the wireless device. In response to determining that changes have occurred to the HSS information, the HSS may determine whether the changes affect the user profile information stored in the user profile repository of the MME. The HSS may generate a changed data communication message including information identifying those changes to the HSS information and send the generated changed data communication message to the MME.

The MME may be configured to receive the altered data communication message and perform operations based on information included in the received altered data communication message. For example, the MME may add subscription information (or user profile information) included in the received changed data communication message to the user profile repository. The MME may also use the information included in the received changed data communication message to modify or delete subscription information (or user profile information) stored in the user profile repository. Further, the MME may be configured to use information included in the received changed data communication message to determine whether a Public Data Network (PDN) subscription context has an associated active PDN connection in the MME, determine whether a subscription quality of service (QoS) profile has been modified, and perform a plurality of subscription QoS modification operations.

In a further embodiment, the MME may be configured to determine whether subscription information and mobility management context of a disconnected wireless device has been deleted, and send a clear communication message to the HSS via the first communication link in response to determining that subscription data and mobility management context of the disconnected wireless device has been deleted. The HSS may be configured to receive the clear communication message and to set a clear flag in response to receiving the clear communication message. That is, in response to the MME determining that the subscription data and Mobility Management (MM) context of the disconnected wireless device has been deleted or removed, the MME component may be configured to send a purge message to the HSS component to cause the HSS component to set a "purge UE for E-UTRAN" flag.

In various embodiments, the DPC component and/or DSC component may be configured to communicate with the HSS component, such as to exchange wireless device subscription information or user profile information. In one embodiment, the DSC component may be configured to request and receive user profile information, subscription information, and DSA-TPA information from the HSS. For example, in response to receiving a "bid wins" message from the DPC, the tenant DSC may be configured to request subscription information from the tenant HSS. The tenant HSS may send tenant DSC subscription information identifying those wireless device subscribers of the tenant network that are to be allowed access to resources won by the tenant network (e.g., resources identified by a "bid win" message). The tenant DSC may then communicate with one or more tenant MMEs associated with the wireless device subscribers (identified by the HSS) to inform the MMEs of those wireless devices that are allowed to use those resources leased.

Various embodiments may also include components configured to perform DSA methods to synchronize user profile information, subscription information, and/or DSA information stored, managed, or maintained by the HSS component and/or MME component. For example, in one embodiment, the HSS component may be configured to determine whether HSS information stored in a memory of the HSS has changed for the wireless device. The HSS component may then determine whether these changes affect the user profile information stored in the user profile repository of the Mobility Management Entity (MME). The HSS component may also generate a changed data communication message including information identifying the changes, and send the generated changed data communication message to the MME. In one embodiment, in response to determining that the changes affect user profile information stored in a user profile repository of the MME, the HSS component may be configured to generate the changed data communication message.

The MME component may be configured to receive the changed data communication message and add information included in the received changed data communication message to a user profile repository of the MME. The MME may also use the information included in the received message to modify the information stored in the user profile repository. Further, the MME may use information included in the received changed data communication message to determine whether a Public Data Network (PDN) subscription context has an associated active PDN connection in the MME and/or to determine whether a subscription quality of service (QoS) profile has been modified. In response to determining that the QoS profile has been modified, the MME component may be configured to perform a plurality of subscription QoS modification operations.

Various embodiments may be implemented in various communication systems, examples of which are illustrated in fig. 1A through 1E. Referring to fig. 1A, a wireless device 102 may be configured to transmit and receive voice signals, data signals, and control signals to and from a base station 111, which may be a Base Transceiver Station (BTS), a NodeB, an eNodeB, and so on. Base station 111 may communicate with access gateway 113, which may include one or more of the following: a controller, a gateway, a Serving Gateway (SGW), a packet data network gateway (PGW), an evolved packet data gateway (ePDG), a Packet Data Serving Node (PDSN), a Serving GPRS Support Node (SGSN), or any similar component or combination of features/functions provided thereby. Since these structures are well known and/or discussed in further detail below, certain details have been omitted from fig. 1A in order to focus on the description of the most relevant features.

Access gateway 113 may be any logical and/or functional component that serves as a primary point of ingress and egress for wireless device traffic and/or connects wireless devices 102 to their instant service provider and/or Packet Data Network (PDN). Access gateway 113 may forward voice signals, data signals, and control signals to other network components as user data packets, provide connectivity to external packet data networks, manage and store context (e.g., network internal routing information, etc.), and act as an anchor point between different technologies (e.g., 3GPP systems and non-3 GPP systems). The access gateway 113 may coordinate the transmission and reception of data to and from the internet 105 and the transmission and reception of voice information, data information, and control information to and from the external service network 104, the internet 105, other base stations 111, and to wireless devices.

In various embodiments, base stations 111 and/or access gateways 113 may be coupled (e.g., via wired or wireless communication links) to a Dynamic Spectrum Arbitrage (DSA) system configured to dynamically manage availability, allocation, access, and use of various network resources (e.g., RF spectrum resources, etc.). DSA systems are discussed in further detail below.

Fig. 1B illustrates that the wireless device 102 may be configured to transmit and receive voice, data, and control signals to and from the serving network 104 (and ultimately the internet 105) using various communication systems/technologies (e.g., GPRS, UMTS, LTE, cdmaOne, CDMA2000TM), any or all of which may be supported by or used to implement various embodiments.

In the example illustrated in fig. 1B, Long Term Evolution (LTE) and/or evolved universal terrestrial radio access network (E-UTRAN) data transmitted from the wireless device 102 is received by the eNodeB116 and sent to a Serving Gateway (SGW)118 located within a core network 120. The eNodeB116 may send signaling/control information (e.g., information related to call setup, security, authentication, etc.) to a Mobility Management Entity (MME) 130. The MME130 may request user/subscription information from a Home Subscriber Server (HSS)132, communicate with other MME components, perform various management tasks (e.g., user authentication, enforcement of roaming restrictions, etc.), select the SGW 118, and send authorization and management information to the eNodeB116 and/or the SGW 118. Upon receiving authorization information (e.g., an authentication complete indication, an identifier of the selected SGW, etc.) from the MME130, the eNodeB116 can send data received from the wireless device 102 to the selected SGW 118. The SGW 118 may store information regarding the received data (e.g., a plurality of parameters of an IP bearer service, network internal routing information, etc.) and forward a plurality of user data packets to a Policy Control Enforcement Function (PCEF) and/or a packet data network gateway (PGW) 128.

Fig. 1B further illustrates that General Packet Radio Service (GPRS) data transmitted from the wireless device 102 may be received by a Base Transceiver Station (BTS)106 and sent to a Base Station Controller (BSC) and/or Packet Control Unit (PCU) component (BSC/PCU) 108. Code Division Multiple Access (CDMA) data transmitted from the wireless device 102 may be received by the base station transceiver 106 and sent to a Base Station Controller (BSC) and/or a Packet Control Function (PCF) component (BSC/PCF) 110. Universal Mobile Telecommunications System (UMTS) data transmitted from the wireless device 102 may be received by the NodeB 112 and sent to a Radio Network Controller (RNC) 114.

BSC/PCU108 component, BSC/PCF 110 component, and RNC 114 component may process GPRS data, CDMA data, and UMTS data, respectively, and send the processed data to components within core network 120. More specifically, BSC/PCU108 unit and RNC 114 unit may send processed data to Serving GPRS Support Node (SGSN)122, and BSC/PCF 110 may send processed data to Packet Data Serving Node (PDSN) and/or high speed packet data serving gateway (HSGW) component (PDSN/HSGW) 126. The PDSN/HSGW 126 may act as a connection point between the radio access network and the IP-based PCEF/PGW 128. SGSN 122 may be responsible for routing data within a particular geographic service area and sending signaling (control plane) information (e.g., information related to call setup, security, authentication, etc.) to MME 130. MME130 may request user and subscription information from Home Subscriber Server (HSS)132, perform various administrative tasks (e.g., user authentication, enforcement of roaming restrictions, etc.), select SGW 118, and send administrative and/or authorization information to SGSN 122.

In response to receiving the authorization information from the MME130, the SGSN 122 may send GPRS/UMTS data to the selected SGW 118. SGW 118 may store information about data (e.g., a plurality of parameters for IP bearer services, network internal routing information, etc.) and forward a plurality of user data packets to PCEF PGW 128. PCEF/PGW 128 may send signaling information (control plane) to Policy Control Rules Function (PCRF) 134. PCRF 134 may access multiple subscriber databases, create policy rule sets, and perform other specific functions (e.g., interacting with online/offline charging systems, application functions, etc.). PCRF 134 may then send the policy rules to PCEF/PGW 128 for enforcement. PCEF/PGW 128 may implement these policy rules to control bandwidth, quality of service (QoS), data characteristics, and services being communicated between serving network 104 and end users.

In various embodiments, any or all of the components discussed above (e.g., component 102 and 134) can be coupled to or included within a DSA system configured for dynamically managing the availability, allocation, access, and use of telecommunications resources.

Figure 1C illustrates the various logical components and communication links in an embodiment system 100 that includes a DSA system 142 and an evolved universal terrestrial radio access network (E-UTRAN) 140. In the example illustrated in fig. 1C, the DSA system 142 includes a Dynamic Spectrum Controller (DSC)144 component and a dynamic spectrum policy controller (DPC)146 component. The E-UTRAN140 includes a plurality of interconnected enodebs 116 coupled to the core network 120 (e.g., via a connection to an MME, SGW, etc.).

In various embodiments, the DSC144 may be included in or coupled to the E-UTRAN140, either as part of its core network 120 or outside of the core network 120. In one embodiment, the DSC144 may be directly coupled (e.g., via a wired or wireless communication link) to one or more enodebs 116.

These enodebs 116 may be configured to communicate with the DSC144 via Xe interface/reference points. In various embodiments, the Xe reference point between DSC and eNodeB116 may use the DSAAP protocol, TR-069 protocol, and/or TR-192 data model extensions to support listing available resources at eNodeB116 and to inform eNodeB116 of bidding/purchase confirmation. The DSC144 may be configured for communication with the DPC146 via an Xd interface/reference point. The Xd reference point between DSC and DPC may use the DSAAP protocol for dynamic spectrum and resource arbitration operations. These enodebs 116 may be interconnected and may be configured for communication via an X2 interface/reference point, which may also communicate data using the DSAAP protocol. These enodebs 116 may be configured to communicate with various components in the core network 120 over an S1 interface. For example, these enodebs 116 may be connected to the MME130 through an S1-MME interface and to the SGW 118 through an S1-U interface. The S1 interface may support a many-to-many relationship between the MMEs 130, SGWs 118, and enodebs 116. In embodiments, the DPC and/or DSC components may also be configured for communication with the HSS132 component.

These enodebs 116 can be configured to provide user plane (e.g., PDCP, RLC, MAC, PHY) and control plane (RRC) protocol termination towards the wireless device 102. That is, the eNodeB116 may act as a bridge (e.g., a layer 2 bridge) between the wireless device 102 and the core network 120 by serving as a termination point for all radio protocols towards the wireless device 102 and relaying voice signals (e.g., VoIP, etc.), data signals, and control signals to multiple network components in the core network 120. The eNodeB116 may also be configured to perform various radio resource management operations, such as controlling the use of the radio interface, allocating resources based on requests, prioritizing and scheduling traffic according to various quality of service (QoS) requirements, monitoring the use of network resources, and so forth. Further, the eNodeB116 may be configured to collect radio signal level measurements, analyze the collected radio signal level measurements, and handover the wireless device 102 (or a connection to a mobile device) to another base station (e.g., a second eNodeB) based on the results of the analysis.

The DSC144 and DPC146 may be functional components configured to manage dynamic spectrum arbitration procedures for sharing radio frequency and other network resources between different E-UTRAN 140. For example, the DPC146 component may be configured to manage DSA operations and interactions between multiple E-UTRAN networks by communicating with multiple DSCs 144 in the E-UTRAN networks.

Fig. 1D illustrates various logical and functional components that may be included in a communication system 101 adapted to perform DSA operations according to various embodiments. In the example illustrated in fig. 1D, the communication system 101 includes eNodeB116, DSC144, DPC146, MME130, SGW 118, and PGW 128.

The eNodeB116 may include a DSC application protocol and congestion monitoring module 150, an inter-cell Radio Resource Management (RRM) module 151, a Radio Bearer (RB) control module 152, a connection mobility control module 153, a radio admission control module 154, an eNodeB measurement configuration and provisioning module 155, and a dynamic resource allocation module 156. Each of these modules 150 and 156 may be implemented in hardware, software, or a combination of hardware and software.

Further, the eNodeB116 may include various protocol layers, including: a Radio Resource Control (RRC) layer 157, a Packet Data Convergence Protocol (PDCP) layer 158, a Radio Link Control (RLC) layer 159, a Medium Access Control (MAC) layer 160, and a Physical (PHY) layer 161. In each of these protocol layers, various hardware components and/or software components may implement functions commensurate with the responsibilities assigned to that layer. For example, the multiple data streams may be received in a physical layer 161, which may include a wireless receiver, a buffer, and multiple processing components that perform operations to demodulate, identify, and extract raw data from a Radio Frequency (RF) signal in order to extract raw data from the received RF signal.

DSC144 may include an eNodeB geographic boundary management module 162, an eNodeB resources and congestion management module 163, a Stream Control Transmission Protocol (SCTP) module 164, a layer 2 (L2) buffer module 165, a layer one (L1) buffer module 166. DPC146 may include an eNodeB resource bid management module 167, an inter-DSC communication module 168, an SCTP/DIAMETER module 169, an L2 buffer module 170, and an L1 buffer module 171. The MME130 may include a non-access stratum (NAS) security module 172 and an idle state mobility handling module 173 and an Evolved Packet System (EPS) bearer control module 174. The SGW 118 may include a mobility anchor module 176. PGW128 may include a UE IP address assignment module 178 and a packet filtering module 179. Each of these modules 162-179 may be implemented in hardware, software, or a combination of hardware and software.

The eNodeB116 may be configured to communicate with the SGW 118 and/or MME130 over an S1 interface/protocol. eNodeB116 may also be configured to communicate with DSC144 over a Xe interface/protocol. The DSC144 may be configured to communicate with the DPC146 via an Xd interface/protocol.

The eNodeB116 can be configured to perform various operations (e.g., via the modules/layers 150 and 161) to provide various functions including functions for radio resource management, such as radio bearer control, radio admission control, connection mobility control, dynamic resource allocation to the wireless device 102 in uplink and downlink (scheduling), and the like. These functions may also include IP header compression and encryption of user data flows, selection of MME at UE attach when routing to MME130 cannot be determined from information provided by the UE, routing of user plane data towards SGW 118, scheduling and transmission of paging information (originating from MME), scheduling and transmission of broadcast information (originating from MME), measurement and measurement reporting configuration for mobility and scheduling, scheduling and transmission of messages (originating from MME) to public alarm systems (e.g., earthquake and tsunami alarm systems, commercial mobile alert services, etc.), Closed Subscriber Group (CSG) handling, and transport level packet tagging in uplink. In one embodiment, the eNodeB116 may be a donor eNodeB (denb) configured to perform various operations to provide a variety of additional functions, such as S1/X2 proxy functions, S11 termination, and/or SGW/PGW functions to support Relay Nodes (RNs).

The MME130 may be configured to perform various operations (e.g., by the module 172 and 175) to provide various functions including non-access stratum (NAS) signaling, NAS signaling security, Access Stratum (AS) security control, inter-CN node signaling for mobility between 3GPP access networks, idle mode UE arrival capability (including control and execution of paging retransmissions), tracking area list management (e.g., for wireless devices in idle and active modes), PGW and SGW selection, MME selection for handover due to MME change, SGSN selection for handover to 2G or 3G 3GPP access networks, roaming, authentication, bearer management functions (including dedicated bearer establishment), support for public warning system (e.g., earthquake and tsunami warning systems, commercial mobile alert services, etc.) message transmission, and performing paging optimization. The MME module may also communicate various device status and attach/detach status information to the DSC. In one embodiment, the MME130 may be configured to filter paging messages towards the macro eNodeB not based on the CSG ID.

The SGW 118 may be configured to perform various operations (e.g., by module 176) to provide various functions including mobility anchoring (e.g., for inter-3 GPP mobility), acting as a local mobility anchor for inter-eNodeB handovers, E-UTRAN idle mode downlink packet buffering, initiating network triggered service request procedures, lawful interception, packet routing and forwarding, transport level packet marking in Uplink (UL) and Downlink (DL), user charging and QoS level identifier (QCI) granularity for inter-operator charging, Uplink (UL) and Downlink (DL) charging (e.g., per device, PDN, and/or QCI), and so on.

PGW128 may be configured to perform various operations (e.g., via module 178-179) to provide various functions including per-user based packet filtering (via, for example, deep packet inspection), lawful interception, UE IP address assignment, transport level packet marking in uplink and downlink, UL and DL service level charging, gating and rate enforcement, APN Aggregated Maximum Bit Rate (AMBR) based DL rate enforcement, and the like.

The DSC144 may be configured to perform various operations (e.g., via the module 162 and 166) to provide various functions including managing resource arbitration operations within a network (e.g., PLMN) for mobility management of tenant wireless devices 102 in a lessor network, tracking network resource lists, tracking bids currently in progress, tracking bids performed, and tracking bid-specific Closed Subscriber Group (CSG) identifiers (CSG-IDs). The DSC144 may be configured to switch the wireless device 102 from a lessee network to a lessee network (i.e., perform a hand-in) and to switch the wireless device 102 from a lessee network to a lessee network (i.e., perform a back-off).

The DSC144 may also be configured to track the congestion status of enodebs, select target enodebs for handover, and manage traffic on leaser enodebs. The DSC144 may be configured to offload users from the tenant network to other, less loaded enodebs 116 within the tenant network based on configured policies (e.g., offload lower priority users, offload higher priority users, offload users with a particular QoS, etc.). The DSC144 may also perform a back-off operation to switch the wireless device 102 from the lessor network back to the lessee network. The DSC144 may also be configured to monitor, manage, and/or maintain historical congestion information collected or received from one or more enodebs in the system.

The DPC146 may be configured to perform various operations (e.g., via modules 167-171) to provide various functions, including acting as a resource arbitration broker between the DSCs 144 of the lessor network and the lessee network (e.g., PLMN), listing resources from the various lessor networks for auctioning, and managing the auction process. The DPC146 may be configured to send notifications of bid-over, bid-winning, bid-cancellation and bid-withdrawal, and bid-expiring to the multiple DSCs 144, install bid-specific charging rules in online and/or offline charging systems of the lessee network and the lessor network, and coordinate resource usage between the DSCs 144 by acting as a gateway between the lessee DSCs 144 and the lessor DSCs 144.

Figure 1E illustrates a number of network components and information flows in an example communication system 103 that includes two E-UTRAN140a, 140b interconnected through a DPC146 configured for managing DSA operations and interactions. In the example illustrated in fig. 1E, each E-UTRAN140a, 140b includes an eNodeB116a, 116b outside its core network 120a, 120b and a DSC144a, 144b inside the core network 120a, 120 b.

The DSCs 144a, 144b may be configured to communicate with the DPC146 over an Xd interface. The DSCs 144a, 144b may also be directly or indirectly connected to various network components in their corresponding core networks 120a, 120b, such as the PCRF 134, the HSS132, and the PCEF/PGW 128 (not shown in fig. 1E). In one embodiment, one or more of the DSCs 144a, 144b may be directly connected to one or more of the enodebs 116a, 116 b.

In addition to the connections and communication links described above, system 103 may include additional connections/links to accommodate data flows and communications between components in different E-UTRAN's (e.g., E-UTRAN140a and 140 b). For example, the system 103 may include a connection/communication link between the eNodeB116 b in the second E-UTRAN140b to the SGW 118 in the first E-UTRAN140 a. As another example, system 103 may include a connection/communication link between SGW 118 in second E-UTRAN140b to PGW128 in first E-UTRAN140 a. These additional components, connections, and communication links are not shown in FIG. 1E in order to focus the discussion on the relevant embodiments.

As discussed in further detail below, the DSCs 144a, 144b may be configured to transmit information regarding the availability of spectrum resources (e.g., information received from enodebs, PCRFs, PCEFs, PGWs, etc.) to the DPC 146. This information may include data relating to the current usage and expected future usage and/or capabilities of each network or sub-network. The DPC146 may be configured to receive and use such information to intelligently allocate, transfer, manage, coordinate, or lease available resources of the first E-UTRAN140a to the second E-UTRAN140b, and vice versa.

For example, the DPC146 may be configured to coordinate allocation of spectrum resources from the E-UTRAN140a (i.e., the lessor network) to the second E-UTRAN140b (i.e., the lessee network) as part of a dynamic spectrum arbitration operation. Such operation may allow a wireless device 102 wirelessly connected to an eNodeB116 b in the second E-UTRAN140b over a communication link 143 to be handed over to the eNodeB116a in the first E-UTRAN140a so that it may use the allocated spectrum resources of the first E-UTRAN140 a. As part of this detach process, the wireless device 102 may establish a new connection 141 to the eNodeB116a in the first E-UTRAN140a, terminate the radio connection 143 to the original eNodeB116 b, and use the allocated resources of the first E-UTRAN140a as if they were included in the second E-UTRAN140 b. These DSA operations may be performed such that the first DSC144a is a lessor DSC for a first resource/time period and a lessee DSC for a second resource or another time period.

In one embodiment, DSA operations and/or detach operations may be performed such that the wireless device 102 maintains a data connection to (or managed by) the original network after it is detached. For example, DSA operations and/or detach operations may be performed such that the wireless device 102 maintains a data flow connection to the PGW128 in the second E-UTRAN140b after being detached to the eNodeB116a in the first E-UTRAN140 a.

Figure 2A illustrates an example DSA method 200 for allocating resources according to one embodiment. The method 200 may be performed by a processing core in a DPC146 component (e.g., a server computing device, etc.).

In block 202, the DPC146 may establish a first communication link to a first DSC144a in a first communication network (e.g., E-UTRAN, etc.). In block 204, the DPC146 may establish a second communication link to the second DSC144b in the second communication network. In block 206, the DPC146 may determine whether Radio Frequency (RF) spectrum resources within the second communication network are available for allocation. This can be done by: the DSAAP protocol is used to communicate with the DSC144 in the second communication network over a second communication link, which may be a wired or wireless communication link. In block 208, the DPC146 may determine an amount of RF spectrum resources available for allocation. In block 210, the DPC146 may perform various operations to allocate all or a portion of the available RF resources of the second communication network for access and use by the plurality of wireless devices 102 in the first communication network.

In block 212, the DPC146 may send a communication message to the first DSC144a (e.g., by using the DSAAP protocol) to inform the first communication network that the first communication network may begin using the allocated FR spectrum resources. In block 214, the DPC146 may record a transaction in a transaction database that identifies an amount of RF spectrum resources allocated for use by the first communication network.

In block 216, the DPC146 may receive a communication message from the second DSC144b that includes information indicating that the allocated resources have been exhausted and/or requesting release of the allocated resources. In block 218, the DPC146 may send a resource exhaustion/release message to the first DSC144a to cause the first network to terminate its use of the allocated resources.

Figure 2B illustrates an example information flow between the DPC146 and the plurality of DSCs 144a-d when performing another embodiment DSA method 250 to allocate resources. In the description below, the DSA method 250 is discussed from the perspective of the DPC146 components and may be performed by a processing core in the DPC 146. However, it should be understood that the DSA method 250 may be performed by multiple processing cores in the DPC146 component, multiple processing cores in the DSC144a-d component, or a combination thereof. Further, it should be understood that all interactions and communications between the DPC146 and other components may be accomplished through multiple DSAAP components and/or using DSAAP protocols. Thus, all such interactions and communications may be included in the DSAAP protocol.

In operation 252, a processing core in the DPC146 component may receive a "resource request" communication message from a first DSC144a component in a first network (e.g., E-UTRAN, etc.). It should be understood that the "resource request" communication message, as well as all other communication messages discussed in this application, may be DSAAP messages.

The "resource request" communication message may include information suitable for informing the DPC146 that the first network is interested in purchasing, leasing, accessing and/or using resources from other networks. The "resource request" communication message may also include information suitable for identifying the type and/or amount of resources (e.g., RF spectrum resources, etc.) requested by the first network, the type and capabilities of those wireless devices 102 to which the requested resources are to be allocated, and other similar information.

In operations 254, 256, and 258, the DPC146 may generate and send "resource query" communication messages to each of the second DSC144b component in the second network, the third DSC144c component in the third network, and the fourth DSC144d component in the fourth network, respectively. The DPC146 may be configured to generate these "resource query" communication messages to include various components, device and resource requirements, criteria and information. For example, the DPC146 may generate a "resource query" communication message to include information identifying the type, capabilities, and geographic criteria of the consumer wireless device 102 to which resources in the first network (and other networks) are to be allocated. The geographic criteria may include the geographic location, geographic polygon, and/or licensed region of the consumer wireless device 102 to which the resource is to be allocated.

In operations 260 and 262, the DPC146 may receive "resource query response" communication messages from the second DSC144b and the third DSC144 c. These "resource query response" communication messages may include information identifying the availability of excess resources that meet the requirements/criteria included in the resource query message. In operation 264, the DPC146 may receive another "resource query response" communication message from the fourth DSC144 d. This "resource query response" communication message may include information indicating that the fourth network does not include resources that meet the requested requirements/criteria.

In one embodiment, as part of operations 260-264, the DPC146 may update the database records to identify the second network and the third network as having resources available for allocation and/or to identify the fourth network as not including such resources.

In operation 266, the DPC146 may generate and transmit a "resource availability" communication message to multiple DSCs in multiple networks (including the first DSC144a in the first network). The DPC146 may be configured to generate a "resource availability" communication message to include information suitable for informing the networks that a plurality of resources are available for allocation. In one embodiment, the DPC146 may be configured to notify the networks that the plurality of resources are available for allocation by broadcasting a communication signal that includes information suitable for notifying the networks that the plurality of resources are available for allocation by auction and/or auction start time of the auction.

In operation 268, the DPC146 may receive a "resource reservation request" communication message from the first DSC144 a. The received "resource reservation request" communication message may include information suitable for notifying the DPC146 that the first network intends to participate in an auction and/or bid on at least a portion of the available resources.

In operations 270 and 272, the DPC146 may send a "resource reservation request" communication message to the second DSC144b and the third DSC144c, respectively. The "resource reservation request" communication message may include information suitable for causing the second DSC144b and third DSC144c to reserve all or a portion of their available resources for allocation and use by other networks.

In operations 274 and 276, the DPC146 may receive a "resource reservation response" communication message from each of the second DSC144b and the third DSC144 c. The "resource reservation response" message may include information suitable for notifying the DPC146 that the requested resource has been reserved and/or information suitable for identifying the reserved resource.

Optionally, in operation block 278, the DPC146 may pool the reserved resources for allocation and use by the plurality of wireless devices 102 in other networks (e.g., the first network). For example, the DPC146 may combine reserved blocks of spectrum in the second network with reserved blocks of spectrum in the third network. As another example, the DPC146 may aggregate available resources in the first and fourth channels of the reserved spectrum block in the second network.

In operation 280, the DPC146 may receive a "resource bid" communication message from multiple networks (including from the first DSC144a in the first network). Each "resource bidding" communication message may include a bid or offer for accessing, using, leasing, and/or purchasing a resource and other relevant bidding information (e.g., price, requested allocation/access method, etc.). As part of operation 280, the DPC146 may determine whether the received resource bid complies with policies and rules of the DSA system and/or with requirements set forth by the network providing the resources for allocation (e.g., meets a minimum ask, etc.).

In operation 282, the DPC146 may accept bids/bids from the first network in response to determining that the resource bids received from the first network are in compliance with those policies/rules of the DSA system and in compliance with a plurality of requirements set forth by the resource providing network (e.g., a monetary amount greater than or equal to a minimum amount specified by the second network is reported for using all or a portion of the resources in the available resource pool). Likewise, in operation 282, the DPC146 may generate and send a "bid accepted" communication message to the first DSC144 a.

In operation 284, the DPC146 may allocate resources of the second network for access and use by the plurality of wireless devices 102 in the first network by sending an "assign resources request" communication message to the second DSC144 b. That is, in operation 284, the DPC may determine that a portion of the resources (e.g., in the pool of available resources) won by the first DSC144a are fully available through the second network, and in response, send only an assign resource request message to the second network.

In operation 286, the DPC146 may receive a "resource allocated" communication message from the second DSC144 b. In operation 288, the DPC146 may send a "resources allocated" communication message to the first DSC144a to inform the first network that these resources have been allocated for access and use by its wireless devices 102 and/or may begin using the allocated resources. In operation block 290, the DPC146 may record transactions in a transaction database that identify these resources as having been allocated for access and use by the first network.

In operation 292, the DPC146 may receive a "release resource" communication message from the second DSC144b that includes information indicating that the allocated resources have been depleted and/or information suitable for requesting release of the allocated resources. In operation 294, the DPC146 may send a resource exhaustion/release message to the first DSC144a to cause the first network to terminate its use of the allocated resources.

Fig. 3-7 illustrate an embodiment DSA method 300 for allocating and accessing resources in a communication system that includes one DPC146 assembly, two DSC144a, 144b assemblies, and a plurality of wireless devices 102. All or part of the DSA method 300 may be performed by the DPC146, DSCs 144 a-144 b, and/or multiple processing cores in the wireless device 102. In various embodiments, any of all interactions and communications between components 146, 144a, 144b, and 102 may be accomplished or facilitated by multiple DSAAP components and/or using DSAAP protocols. Thus, all such interactions and communications may be included in the DSAAP protocol.

Referring to fig. 3, in block 302, the first DSC144a in the first network may monitor user traffic (e.g., call traffic, data traffic, etc.) as compared to the total spectrum resources available to the first network. In block 304, the first DSC144a may generate a resource status report based on the results of its monitoring, record/store the resource status report in memory, and send the resource status report to the DPC146 via a resource status report communication message. In determination block 306, the first DSC144a may determine whether additional resources are needed (and/or whether there is a high likelihood that additional resources will be needed in the near future) to provide appropriate services to existing wireless devices 102 in the first network based on the received resource status reports. In response to determining that additional resources are needed (i.e., determination block 306 ═ yes), the first DSC144a may send a "resource request" communication message to the DPC146 in block 308. In response to determining that no additional resources are needed (i.e., determination block 306 ═ no), in block 302, the first DSC144a may continue to monitor user traffic and/or perform other DSC operations.

In block 310, the second DSC144b in the second network may monitor user traffic compared to the total spectrum resources available to the second network, generate a resource status report, and/or perform any or all of the DSC operations discussed in this application. In determination block 312, the second DSC144b may determine whether there is an excess amount of resources available in the second network. In response to determining that there are no excess resources available in the second network (i.e., determination block 312 ═ no), in block 310, the second DSC144b may continue to monitor user traffic and/or perform other DSC operations.

In response to determining that there is an amount of excess resources available in the second network (i.e., determining that block 312 is yes), in block 314, the second DSC144b may mark, designate, or allocate all or a portion of its excess resources for access and use by other networks (e.g., the first network, etc.). In block 316, the second DSC144b may generate a resource allocation report and send the generated resource allocation report to the DPC146 (e.g., via a resource communication message). The DSC144b may be configured to generate a resource allocation report to include information identifying resources (or portions or amounts of resources) that are available for allocation and/or have been marked, specified, or allocated by the second network.

In block 320, the DPC146 may receive various resource status and allocation reports from the DSCs 144 in a number of different networks, including the first DSC144a and the second DSC144b in the first network and the second network. These reports may include information identifying various characteristics, criteria, requirements, and conditions of the networks and their components (e.g., the ratio of detected user traffic to total available spectrum resources), the amount of resources required by the networks, the amount of resources available for allocation in the networks, the type and capabilities of the wireless device 102 that is to use the allocated resources, system requirements that must be met before the wireless device 102 accesses the allocated resources, network rules and policies regarding access and use of resources, and other similar information.

In block 322, the DPC146 may store the received report (e.g., a resource status report, a resource allocation report, etc.) in a memory (e.g., a non-volatile memory). In block 324, the DPC146 may receive a resource request from the DSCs 144 in different networks (including the first DSC144a in the first network). In block 326, the DPC146 may use the received/stored information (e.g., information received in the resource request, resource allocation report, resource status report, etc.) to identify and select the most appropriate/best available network from which the first network may lease or purchase additional resources. In the example illustrated in fig. 3, the DPC146 identifies and selects the second network as the most appropriate network to provide resources to the first network.

In block 328, the DPC146 may send a resource query communication message to the second DSC 1144 b. In block 330, the second DSC 1144b may receive a resource query communication message. In block 332, the second DSC 1144b may determine the availability, amount, and/or quantity of excess resources marked, specified, or allocated by the second network. In block 334, the second DSC 1144b may generate and send a "resource query response" communication message to the DPC 146. The second DSC 1144b may generate the resource query response to include information suitable for identifying the availability and quantity of resources identified, designated, or allocated for access and use by other networks (e.g., the first network). In block 336, the DPC146 may receive a "resource query response" communication message from the second DSC 1144b and, in response, perform the operations of determination block 400 illustrated in fig. 4.

Referring to fig. 4, in determination block 400, the DPC146 may determine whether the resource is available based on data (e.g., a resource query response message) received from the second DSC144b in the second network. For example, in response to determining that all or a portion of the resources were purchased or won by other bidders before being reserved, DPC146 may determine that the identified resources are unavailable.

In response to determining that resources are not available (i.e., determination block 400 — no), in block 402, the DPC146 may send a "no resources available" communication message to the first DSC144a in the first network. In block 404, the first DSC144a may receive the "no resources available" communication message. In block 406, the first DSC144a may search for other available resources (e.g., through the DPC 146), request resources from a different network, request different resources, terminate a connection or communication session with a user to vacate resources, or perform other similar operations to manage network traffic and congestion in the first network.

In response to determining that resources are available (i.e., determination block 400 — yes), the DPC146 may send a "resources available" communication message to the first DSC144a in block 408. The resource available message may include information that may be used by the first DSC144a to determine the quality and quantity of resources available in the second network for use by wireless devices 102 in the first network.

In block 410, the first DSC144a may receive a resource available communication message transmitted from the DPC 146. In block 412, the first DSC144a may determine the amount/quantity of resources required by the first network and/or to be attempted to acquire, and send this and other resource information to the DPC146 in a "request resources" communication message.

In block 414, the DPC146 may receive a "request resource" message from the first DSC144 a. In block 416, the DPC146 may generate and send a "reserve resource request" communication message to the second DSC144b in the second network using the information included in the received message.

In block 418, the second DSC144b may receive a "reserve resource request" message from the DPC 146. In block 420, the second DSC144b may reserve the requested amount of allocated resources for access and use by multiple components in other networks using information included in the received "reserve resource request" message. In block 422, the second DSC144b may send a "resources reserved" communication message to the DPC146 to confirm that the requested amount of resources have been reserved and/or to identify the reserved resources.

In block 424, the DPC146 may receive a "resource reserved" communication message from the second DSC144 b. In block 426, the DPC146 may provide the reserved resources for the auction and/or begin accepting resource bids for the reserved resources.

Figure 5 illustrates a bidding process of the DSA method 300 that may be performed after the DPC146 provides the reserved resources for the auction and/or begins accepting a resource bid for the reserved resources (e.g., after performing those operations of block 426 illustrated in figure 4).

Referring to fig. 5, in block 500, the first DSC144a in the first network may negotiate access to reserved resources of the second network by sending a resource bid (e.g., via a communication message) to the DPC 146. In block 502, the DPC146 may receive a resource bid from the first DSC144 a.

In determination block 504, the DPC146 may determine whether to accept the received resource bid, which may be accomplished by determining whether the resource bid complies with the policies and rules of the DSA system and the requirements of the second network (e.g., greater than a minimum amount, etc.). In response to determining to accept the resource bid received from the first DSC144a (i.e., determination block 504 — yes), the DPC146 may send an "accept bid" communication message to the first DSC144a in block 506. In block 508, the first DSC144a may receive an "accept bid" message and wait to receive a resource access instruction. In block 510, the DPC146 may send an "assign resources" communication message to the second DSC144b in the second network.

In block 512, the second DSC144b may receive an "assign resources" communication message from the DPC 146. In block 514, the second DSC144b may use the information included in the received "assign resources" message to assign all or part of the resources it reserved for access and use by multiple components in the first network. In block 516, the second DSC144b may generate and send a "resource access" communication message to the DPC146 that includes information (e.g., access parameters, etc.) that may be used by the wireless device 102 (i.e., in the first network) to access the assigned resources. In block 518, the second DSC144b may perform various operations in preparation for establishing a communication session/link with the wireless device 102 in the first network, such as by configuring or preparing to receive a voice call or a data call.

In block 522, the DPC146 may receive a "resource access" communication message from the second DSC144b and relay the resource access message to the first DSC144 a. In block 524, the first DSC144a may receive a "resource access" message from the DPC 146. The received "resource access" message may include a plurality of access parameters that may be used by the wireless device 102 to access the allocated resources of the second network. In block 526, the first DSC144a may send access parameters to wireless devices 102 that have a communication session with the first network and/or to wireless devices 102 that the first network has designated/tagged for migration to other networks.

In block 528, the wireless device 102 may receive access parameters for the second network from the first DSC144 a. In blocks 530 and 520, the wireless device 102 and/or the second DSC 142b may perform various operations to establish a communication session/link between the wireless device 102 and the second network. The second DSC144b may then perform those operations of block 700 illustrated in fig. 7 and discussed further below.

As described above, in determination block 504, the DPC146 may determine whether to accept the resource bid received from the first DSC144 a. In response to determining that the resource bid received from the first DSC144a is not accepted (i.e., determination block 504 ═ no), the DPC146 may perform those operations of block 600 shown in fig. 6.

Referring to fig. 6, in block 600, the DPC146 may send a "decline bid" communication message to the first DSC144 a. In block 602, the first DSC144a may receive the "decline bid" message from the DPC 146. In determination block 604, the first DSC144a may determine whether the first network will/should re-bid for these resources. In response to determining that the first network will/should re-bid for the resource (i.e., determination block 604 ═ yes), in block 606, the first DSC144a may send a new resource bid (e.g., in a resource bid communication message) to the DPC 146.

In block 608, the DPC146 may receive the new resource bid (or re-bid) from the first DSC144 a. In determination block 610, the DPC146 may determine whether to accept the new resource bid, such as by determining whether the new resource bid complies with the policies and rules of the DSA system and the requirements of the second network. In response to determining to accept the new resource bid (i.e., determining block 610 — yes), DPC146 may perform those operations of block 506 illustrated in fig. 5. Responsive to determining that the new resource bid is not accepted (i.e., determination block 610 ═ no), DPC146 may perform those operations of block 600.

In response to determining that the first network should re-bid for resources (i.e., determination block 604 ═ no), the first DSC144a may send a "cancel resource request" communication message to the DPC146 in block 612. In block 614, the DPC146 may receive a "cancel resource request" message from the first DSC144 a. In block 616, the DPC146 may send a "resource release" communication message to the second DSC144 b.

In block 618, the second DSC144b may receive the "resource release" message from the DPC 146. In block 620, the second DSC144b may release the reserved resources so that they may be used by other networks. The secondary DSC144b may then report the status of the allocated resources to the DPC146, which may be accomplished by performing those operations of block 316 illustrated in fig. 3 and discussed above.

Figure 7 illustrates a settlement process of the DSA method 300 that may be performed after the second network provides access to the secondary consumer wireless device 102 in the first network (i.e., after performing the operations of block 520 illustrated in figure 5).

In block 700, the second DSC144b may send invoices and payment instructions to the DPC146 related to the use of the allocated resources by the first network. In block 704, the DPC146 may relay the received invoice and payment instructions to the first DSC144 a. In block 706, the first DSC144a may receive these invoice and payment instructions and settle the charges for the second network in block 718.

Optionally or alternatively, in block 708, the second DSC144b may send a plurality of usage parameters and a plurality of payment instructions to the DPC 146. In block 710, the DPC146 may receive the usage parameters and payment instructions from the second DSC144 b. In block 712, the DPC146 may create an invoice for the access and use of the resource. In block 714, the DPC146 may send an invoice to the first DSC144a in the first network. In block 716, the first DSC144a may receive these invoice and payment instructions and perform various operations in block 718 to settle the charges for the second network.

In various embodiments, the DPC146 and DSC144 components may be configured to communicate over an interface, which may be implemented in or provided by the Dynamic Spectrum Arbitration Application Part (DSAAP) protocol/module/component defined above on the Xe reference point and/or the Xd reference point. The DSAAP may allow, facilitate, support, or increase communication between the DPC146 and the DSC144 in order to improve the efficiency and speed of DSA systems and telecommunications networks. In various embodiments, all or a portion of the DSAAP modules/components may be included in the DPC146 component, the DSC144 component, components separate from the DPC146 and DSC144 components, or any combination thereof. The DSAAP modules/components may allow these and other DSA components to communicate information using DSAAP protocols.

For example, DSAAP may allow the DPC146 and DSC144 components to communicate certain information and/or perform a variety of operations that together provide various functions, including: DSC register function, resource availability advertisement function, bidding and allocation function for resources, cut-out of tenant users to a lessor network function, back-off from a lessor network function, error handling function (e.g., reporting function for general error cases for which no specific error message is defined, etc.), DSC logout function, error indication function, DSC bidding success and failure indication function, and DSC resource allocation revocation function. In various embodiments, these functions may be provided, implemented, or accomplished by configuring the DPC146 component and/or the DSC144 component to perform one or a combination of the DSAAP methods discussed below with reference to fig. 8A-17B. Using the DSAAP protocol and performing the DSAAP methods may include communicating via one or more DSAAP messages.

In various embodiments, DSAAP messages used to communicate information between DSC144 and DPC146 may include DSC registration request messages, DSC registration accept messages, DSC registration reject messages, DSC deregistration messages, DSC resource registration request messages, DSC resource registration accept messages, DSC resource registration reject messages, available bid request messages, available bid response messages, available bid reject messages, DSC bid request messages, DSC bid accept messages, DSC bid reject messages, DSC bid over-bid messages, DSC bid win messages, DSC bid failure messages, DSC bid cancel messages, DSC purchase request messages, DSC purchase accept messages, DSC purchase reject messages, DSC resource allocated messages, DSC resource withdrawal messages, and/or DSC backoff command messages. Each of these messages may include or may be associated with criticality information, presence information, scope information, and assigned criticality information. These messages and their contents are discussed in further detail below.

In various embodiments, the DSAAP methods may be performed in a DSA system that includes a first DSC server in a first telecommunications network (e.g., a tenant network), a second DSC server in a second telecommunications network (e.g., a lessor network), and a DPC server outside of the first and second telecommunications networks. The first DSC may comprise a first DSC processor coupled to the DPC through a first communication link, and the second DSC may comprise a second DSC processor coupled to the DPC through a second communication link. The second DSC may be coupled to an eNodeB in the second telecommunication network through a third communication link. The first and second communication links may be defined on an Xd interface and the third communication link may be defined on an Xe interface.

Fig. 8A-8C illustrate an embodiment DSAAP registration method 800 for registering DSC144 components with DPC146 to allow DPC146 to provide DSC144 with various services (e.g., advertising renter DSC 144's resources for bidding, allowing lessee DSC144 to bid on resources provided by other networks, etc.). In the example illustrated in fig. 8A through 8C, the DSAAP registration method 800 is performed by a processing core in the DPC146 component and the DSC144 component, each of which may include all or part of a DSAAP module/component. The operation of the DSAAP registration method may be performed after or in response to the DSC144 or DPC146 detecting that an XE signaling transfer or communication link has been established.

In operation 802 illustrated in fig. 8A through 8C, the DSC144 may initiate the DSAAP registration method 800 by generating a DSC register request message and sending it to the DPC 146. In one embodiment, in response to determining that it requires service from the DPC146, the DSC144 may be configured to generate and/or transmit a DSC register request message. For example, in response to determining that its respective network (i.e., the network represented by the DSC) includes excess resources that may be allocated to other networks, the DSC144 may be configured to generate a DSC register request message. As another example, in response to determining that its network requires additional resources to provide appropriate services to its existing wireless devices 102 in view of current or anticipated future user traffic, network congestion, etc., DSC144 may be configured to generate a DSC register request message.

In various embodiments, the DSC144 may be configured to generate a DSC register request message to include any or all of the following: a message type Information Element (IE), a message ID IE, a DSC identity IE, a DSC Internet Protocol (IP) address IE, a DSC type IE, a DSC PLMN-ID IE, a PLMN type IE, and a DSC resource update timer IE. The DSC PLMN-ID IE may include a PLMNID suitable for identifying a network (e.g., E-UTRAN) associated with or represented by DSC 144. The PLMN type IE may include information suitable for determining the type of network represented by the DSC144 (e.g., public safety, commercial, etc.). The DSC IP address IE may include the IP address of the DSC144 responsible for managing, maintaining, or providing the XE interface of the DSAAP.

In operation block 804 illustrated in fig. 8A and 8B, the DPC146 may perform various registration operations (i.e., authenticating the DSC, storing DSC identifier information in memory, etc.) to register the DSC144 with the DPC 146. In one embodiment, as part of these registration operations, the DPC146 may overwrite/overwrite an existing registration with a new registration, such as in response to receiving a repeated DSC registration request message (i.e., for an already registered DSC identified by the same unique DSC identity).

In operation block 806, illustrated in fig. 8A, the DPC146 may determine that the registration operations were successful. In operation 808, the DPC146 may generate and transmit a DSC register accept message to the DSC144 to indicate acceptance and registration of the DSC 144. In various embodiments, the DPC146 may generate the DSC register accept message to include any or all of the following: message type Information Element (IE), message ID IE, DPC ID IE, XEh signaling network layer (TNL) address IE, and tunneling information IE. The XEh signalling TNL address IE may comprise an address value suitable for establishing a transport layer session. The tunneling information IE may include information that may be used to encapsulate different payload protocols, establish secure communications over untrusted or unverified networks, carry payloads over incompatible delivery networks, and/or perform other similar tunneling operations.

To support XEh connectivity through/to the DPC146, in operation block 810, the DSC144 may establish a transport layer session using the XEh signaling TNL address IE included in the DSC registration accept message. In one embodiment, in response to determining that the DSC register accept message includes an address value in the XEh signaling TNL address information element, the DSC144 may be configured to establish a transport layer session. In one embodiment, in response to determining that the XEh signaling TNL address information element is not present, is zero, is null, or is invalid, the DSC144 may be configured to determine that XEh connectivity through/to the DPC146 is not supported or required.

Referring now to fig. 8B, in operation block 812, DPC146 may determine that those registration operations performed as part of operation 804 failed. The DPC146 may determine that registration has failed in response to detecting any of a variety of conditions/events, including failure to authenticate or authorize the DSC, network or component overload, DSC parameter mismatch, etc. In operation 814, the DPC146 may generate and send a DSC register reject message to the DSC144 to notify the DSC144 that registration failed and/or the DPC146 could not register the DSC 144. In various embodiments, the DPC146 may generate the DSC register reject message to include any or all of the following: a message type Information Element (IE), a message ID IE, a cause IE, a criticality diagnosis IE, and a backoff timer IE. The cause IE may include information suitable for identifying a particular cause of failure (e.g., overload, etc.) or for indicating that the cause of failure is unknown or unspecified.

In operation block 816, the DSC144 may perform various registration failure response operations based on the information included in the received registration reject message. For example, in response to determining to set the value of the cause IE in the received registration reject message to "overloaded," DSC144 may wait for the duration indicated in the backoff timer IE in the received registration reject message before reattempting to register the same DPC 146.

Referring to fig. 8C, in operation block 852, in response to sending a DSC register request message to DPC146 (e.g., as part of operation 802), DSC144 may start a register response timer. In operation block 854, the DSC144 may determine that the registration response timer expires before the DSC144 receives a DSC registration response message. In operation 856, in response to determining that the timer expires before it receives the corresponding DSC register response message, the DSC144 may retransmit a DSC register request message to the DPC 146. In operation block 858, the DSC144 may restart or reset the registration response timer. In operation 860, the DPC may transmit a DSC register response message to the DSC 144. In operation block 862, the DSC144 may block the registration response timer in response to receiving the DSC registration response message.

Figures 9A and 9B illustrate a DSAAP advertising method 900 for advertising resources available for bidding/purchase to allow the DPC146 to store, organize and/or make available those resources for bidding/allocation through the financial brokerage platform. In the example illustrated in fig. 9A and 9B, the DSAAP advertising method 900 is performed by a processing core in the DPC146 component and the DSC144 component, each of which may include all or part of a DSAAP module/component.

In operation block 902 illustrated in fig. 9A and 9B, DSC144 may determine that there are resources available for allocation within a plurality of cells served by that DSC 144. In operation block 904, the DSC144 may generate and send a DSC resource registration request message to the DPC 146. In various embodiments, the DSC144 may generate a DSC resource registration request message to include any or all of the following: a message type Information Element (IE), a message ID IE, a DSC identification IE, a DSC type IE, a PLMN-ID list IE, a resource availability start time IE, a data bandwidth IE, a grid list IE, a bid or purchase IE, a minimum bid amount IE, a resource availability end time IE, a duration IE, a megabit per second (MBPS) IE, and a cell identification IE.

The DSC identity IE may include information that may be used by the DPC146 to determine the identity of the DSC 144. For example, the DSC identification IE may include a DSC pool ID, DSC instance information, and a PLMN ID of the network that the DSC is managing or representing. The DSC pool ID may be a unique identifier of the available resource pool and/or may be the same or similar to the MME pool ID and MME ID in the 3GPP EPC architecture.

The message ID IE may include a message identifier for a particular DSC resource registration request message sent from DSC 144. The DSC144 and DPC146 may be configured to use the message ID IE as a sequence number to identify and associate DSC resource registration request messages, DSC resource registration accept messages, and/or DSC resource registration reject messages.

The resource availability IE may include information suitable for use by the DPC146 to determine the PLMN ID of the network that is advertising the resource for allocation and use by other networks. The DPC146 may be configured to receive, store and/or maintain resource availability IEs for multiple DSCs and/or for multiple different networks (i.e., different PLMN IDs). Thus, each resource availability IE may include information suitable for identifying one or more of those networks that are advertising resources.

The time IE may include information suitable for use by the DPC146 to determine the time at which the DSC144 transmitted the DSC resource registration request message. The duration IE may include information suitable for determining a time period during which the resource is to be made available for bidding or purchase.

The data bandwidth IE may include information suitable for determining the available bandwidth (i.e., represented in MBPS) for the duration specified in the optional duration IE. In response to determining that the duration IE is not included in the received DSC resource registration request message (or in response to determining that the duration IE does not include a valid value), the DPC146 may determine that the bandwidth specified in the MBPS IE is made available until the bandwidth is exhausted by the winning bidder or purchaser.

The mesh list IE may include information for a plurality of mesh identifiers suitable for determining the location of network bandwidth to be available for bidding or purchase. The cell identification IE may include information suitable for determining the various cells (identified by grid IDs and cell IDs) within each grid that have available resources offered for bidding or purchase as part of the bid in the DSC resource registration request message. The minimum bid amount IE may include a monetary amount expressed in denomination or banknote (e.g., in U.S. dollars (USD)).

In operation block 906, illustrated in fig. 9A, the DPC146 may accept the resources of the DSC144 for bidding. In operation 908, the DPC146 may generate and send a DSC resource registration response message or DSC resource registration accept message to the DSC144 confirming that these resources are accepted. In various embodiments, the DPC146 may generate the DSC resource registration message to include any or all of the following: a message type Information Element (IE), a bid ID IE, and a message ID IE. The message IDIE may include the same message identifier value included in the received DSC resource registration request message. The DPC146 and/or DSC may be configured to use the value of the message ID IE to identify and associate the DSC resource registration request message and DSC resource registration accept message. In operation block 910, the DPC146 may store, organize, and/or make available network resources to bid or purchase through the financial brokerage platform.

In operation 912, illustrated in fig. 9B, the DPC146 may reject the DSC resource registration request message and/or reject bidding on the resource identified in the received DSC resource registration request message. The DPC146 may reject the message/resource for a variety of reasons and/or in response to detecting any of a variety of events or conditions. For example, the DPC146 may reject resources in response to determining that the DPC146 did not accept resources from any operator, did not accept resources for a particular operator identified in the received message, did not accept resources identified in the message, the DPC was overloaded, insufficient memory was available to store and service resources available for bidding, etc. The DPC146 may also reject the resource available message in response to determining that the administrator of the DPC146 has disabled the particular PLMN ID from inclusion in the DSC resource registration request message, further bidding from all networks (e.g., all PLMN IDs), etc.

In operation 914 illustrated in fig. 9B, the DPC146 may generate and send a DSC resource registration reject message to the DSC 144. In various embodiments, the DPC146 may generate the DSC resource registration reject message to include any or all of the following: a message type Information Element (IE), a message ID IE, a cause IE, and a criticality diagnosis IE. The DPC146 may also generate the DSC resource registration reject message to include a message ID IE that includes the same value as the message identifier included in the DSC resource registration request message received from the DSC 144. The DPC146 and/or DSC144 may be configured to use the value of the message ID IE to identify and associate DSC resource registration request messages and DSC resource registration reject messages.

In operation block 916, the DSC144 may perform various resource registration failure response operations based on the information included in the received DSC resource registration reject message. For example, the DSC144 may use the information included in the DSC resource registration reject message to determine whether to reattempt to register a resource with the DPC146, attempt to register a resource with another DPC, reattempt to register a different resource, or perform any of the other DSC operations discussed in this application.

Fig. 10A and 10B illustrate a DSAAP method 1000 for communicating a list of available resources according to one embodiment. DSAAP method 1000 may be performed to notify multiple tenants of resource bids or resources available for bidding/purchasing by the network. In the example illustrated in fig. 10A and 10B, DSAAP method 1000 is performed by a processing core in a DPC146 component and a DSC144 component, each of which may include all or part of a DSAAP module/component. In one embodiment, the tenant DSC144 may be configured to execute the DSAAP method 1000 to retrieve/receive a list of available resources before the DSC144 bids on, or requests to lease or purchase, resources from the DPC 146.

In operation 1002 shown in fig. 10A and 10B, the lessee DSC144 may generate and send an available bid request message to the DPC146 to request information from the lessor network available for allocation of resource bids for bidding or purchase. In various embodiments, tenant DSC144 may generate an available bid request message to include any or all of the following: a sequence number Information Element (IE), a message type IE, a PLMN list IE including one or more PLMN ID IEs, a mesh ID list IE including one or more mesh ID IEs.

In one embodiment, tenant DSC144 may be configured to request a particular resource from a desired network by generating an available bidding request message to include a PLMN ID for a particular network, which may be included in a PLMN ID IE of a PLMN list IE in the available bidding request message.

In one embodiment, tenant DSC144 may be configured to request resources from any available network by not populating PLMN list IEs in the generated available bid request message and/or by generating an available bid request message to not include PLMN list IEs and/or PLMN ID values.

In one embodiment, tenant DSC144 may be configured to request resources from a desired grid by generating an available bid request message to include the grid ID of a particular grid, which may be included in the grid ID IE of the grid ID list IE in the available bid request message.

In one embodiment, tenant DSC144 may be configured to request resources from any or all grids within a specified PLMN ID in a PLMN ID IE grid by not populating grid ID list IEs in the generated available bid request message and/or by generating an available bid request message to not include grid IDs.

In operation block 1004, shown in fig. 10A and 10B, DPC146 may determine whether the PLMN ID and mesh ID included in the received available bid request message are valid. If the PLMN ID and mesh ID are incorrect, the DPC146 may determine a cause code for the incorrect/incorrect value in operation block 1005. In operation block 1006, DPC146 may determine whether there are resources/bids available for each of the cells identified in the received available bid request message or for all available cells (e.g., when the cell ID list IE in the received available bid request message does not include a valid value).

In operation 1008, illustrated in fig. 10A, the DPC146 may generate and send an available bid response message to the DSC 144. DPC146 may be configured to generate available bid response messages to include any or all of the following: a message type Information Element (IE), a message ID IE, a DSC identification IE, a PLMN-ID mesh cell bidding information list IE, a sequence number IE, a PLMN list IE including one or more PLMN ID IEs, and a mesh list IE. In one embodiment, the PLMN list IE and the grid list IE may be included in the PLMN-ID grid cell bidding information list IE. In one embodiment, the mesh list IE may include one or more cell ID list IEs that include one or more cell ID IEs.

In various embodiments, DPC146 may generate the available bid response message to further include any or all of the following: an Absolute Radio Frequency Channel Number (ARFCN) IE, a channel bandwidth IE, a megabit or megabyte IE for identifying total available bandwidth, an MBPS IE for identifying peak data rate of a resource, a resource availability time IE, a resource expiration time IE, a bid/purchase expiration time IE, a minimum bid scalar IE, and a purchase price IE. DPC146 may generate an available bid response message to include such information for each PMLN, each resource, each grid, and/or each cell identified in the message.

In one embodiment, responsive to determining that there is a bid for resources available for auction, DPC146 may be configured to generate an available bid response message to include a list of PLMN IDs, a plurality of lists of grid IDs within each PLMN, and available resources/bids within each grid.

In one embodiment, in response to determining that there are no resources/bids for resources available for auction by the DPC146 for the associated network/PLMN ID, the DPC146 may be configured to generate an available bid response message to include a message type IE and a sequence number IE (or valid values of these IEs). In one embodiment, DPC146 may be configured to generate an available bid response message to include a sequence number IE having the same value as in the sequence number IE included in the received available bid request message. In one embodiment, the DSC144 may be configured to associate the request messages and response messages using sequence number IEs in the messages.

In one embodiment, DPC146 may be configured to generate an available bid response message to include a PLMN list IE containing PLMN IDs and a mesh ID list IE. The grid ID list IE may include a list of cells available for auction within the grid. The cell ID list IE may include the cell ID, as well as the ARFCN for each cell, channel bandwidth, total available bandwidth, peak data rate allowed, resources available and time they expire/end (e.g., in UTC), whether or not it is a bid or type of purchase auction, minimum bid amount or purchase price, bid expiration time (e.g., in UTC), and other similar information.

In operation block 1010, DSC144 may use information included in the available bid response message to identify resources available for bidding, determine whether DSC144 will submit a bid for the available resources, determine resources for which a bid will be submitted by DSC144, and/or perform other similar operations.

Referring to fig. 10B, in operation 1012, DPC146 may reject the available bid request message received from tenant DSC144 by generating and sending an available bid reject message to DSC 144. Responsive to determining (e.g., as part of operations 1004 or 1006) that one or more of the PLMN IDs provided in the request message are not from any known network, that one or more of the grid IDs provided in the request message are not valid with respect to the provided PLMN IDs, and/or that no resources/bids are available within the associated grid, DPC146 may be configured to reject the available bid request message.

In one embodiment, DPC146 may be configured to generate an available bid rejection message to include a message type Information Element (IE), a message ID IE, a cause IE, a criticality diagnosis IE, and a sequence number IE. The reason IE may include a reason code for rejection of the available bid request (e.g., invalid PLMN ID, invalid mesh ID, etc.), which may be determined in operation block 1005. The sequence number IE may include the same sequence number value as included in the available bid request message received from tenant DSC 144. Accordingly, DPC146 and/or DSC144 may be configured to correlate request and response messages using sequence number IEs in those messages.

In operation block 1014, the DSC144 may perform various failure response operations using the information included in the received available bid rejection message. For example, DSC144 may determine whether to send an available bid request message to DPC146, determine whether to send another available bid request message to a different DPC, and so on.

Fig. 11A and 11B illustrate a DSAAP bidding method 1100 for bidding on DSC resources that allows different lessee networks to bid on resources available from multiple lessor networks. In the example illustrated in fig. 11A and 11B, DSAAP method 1100 is performed by a processing core in a DPC146 component and a DSC144 component, each of which may include all or part of a DSAAP module/component.

In one embodiment, the DSC144 and/or DPC146 may be configured to perform the DSAAP method 1100 after the DSC144 retrieves a list of resources available for bidding (e.g., after performing the DSAAP method 1000). In various embodiments, DSC144 and/or DPC146 may be configured to continuously or repeatedly perform DSAAP method 1100 until the bid time expires. In one embodiment, DPC146 may be configured to select a winning bid (i.e., bid the highest bid value) when the bid time expires.

In operation 1102 of the method 1100 shown in fig. 11A and 11B, the tenant DSC144 may generate and send a DSC bid request message to the DPC146 to bid on one or more of the resources determined to be available from the lessor network (i.e., one or more resources included in the resource list obtained through execution of the method 1000). The tenant DSC144 may be configured to generate a DSC bid request message to include any or all of the following: a message type Information Element (IE), a message ID IE, a DSC identification IE, a DSC type IE, a bid ID IE, a PLMN ID IE, and a bid amount IE. The bid ID IE may include information suitable for identifying the particular resource for which the tenant DSC144 is bidding. The PLMN ID IE may include information suitable for identifying a PLMN ID of a network associated with the resource identified in the bid ID IE. The bid amount IE may include a monetary amount or bid value in terms of banknotes (e.g., USDs).

In one embodiment, the tenant DSC144 may be configured to generate a DSC bid request message to include a bid amount IE value that is greater than a minimum bid amount specified in the bid list for a particular resource/bid ID. In one embodiment, tenant DSC144 may be configured to obtain a minimum bid amount and/or a list of bids from received available bid response messages (e.g., messages sent as part of operation 1008 shown in fig. 10A).

In operation block 1104, shown in fig. 11A, the DPC146 may use information included in the received DSC bid request message to determine whether a bid (resource bid) is valid and will be accepted, such as by determining whether the bid complies with the policies and rules of the DSA system and the requirements of the lessor network. In operation 1106, in response to determining that the bid is valid and/or is to be accepted, the DPC146 may generate and send a DSC bid accept message to the DSC. The DPC146 may be configured to generate a DSC bid accept message to include any or all of the following: a message type Information Element (IE), a message ID IE, a bid ID IE, and other information suitable for informing DSC144 that the bid has been determined to be valid and/or accepted.

It should be noted that in the example discussed above, the DSC bid accept message informs DSC144 that the bid is valid/accepted rather than the lessee DSC144 having won the bid. When DPC146 determines that the bidding time has expired and that the lessee DSC is the highest bidder at the time the bid expires, the winning lessee DSC may be notified by the DSC bid win message. Similarly, DPC146 may notify one or more tenants participating in the bidding process but submitting a failed bid that they did not submit a winning bid via a DSC bid failure message. The DSC bid win message and DSC bid failure message are discussed in further detail below.

Referring to fig. 11B, in operation block 1108, the DPC146 may use information included in the received DSC bid request message to determine that the bid is invalid and will not be accepted. For example, the DPC146 may use the received information to determine that the bid does not comply with the policies/rules of the DSA system and/or does not comply with the requirements of the lessor network (e.g., does not meet a minimum ask, etc.). As a further example, in response to determining that a particular bid amount in the bid amount IE in the bid request message is not above a minimum bid, that the bid amount is not the highest amount in the current bid, that the bid ID included in the bid ID IE is invalid or that the bid/resource is no longer available for bidding (e.g., due to expiration, auction close, bid withdrawal, or invalid bid ID), the DPC146 may be configured to determine that the bid is invalid or not accepted.

In operation 1110, the DPC146 may generate and send a DSC bid rejection message to the DSC 144. The DPC146 may be configured to generate the DSC bid rejection message to include any or all of the following: a message type Information Element (IE), a message ID IE, a bid ID IE, a cause IE, and a criticality diagnostic IE. The bid IDIE in the DSC bid rejection message may include the same value as the bid identifier included in the received DSC bid request message. The reason IE may include a reason code identifying the reason for declining a bid (e.g., a minimum bid has not been met, bids have been placed too high, bids have not been found, etc.). In operation block 1112, the DSC144 may use the information included in the received DSC bid rejection message to perform various bid request failure response operations, such as operations to determine whether to re-bid resources, generate a new DSC bid request message including a valid bid ID, and so on.

Figures 12A through 12D illustrate a DSAAP notification method 1200 that notifies participating networks of the outcome of the bidding operations. That is, the DSAAP notification method 1200 may be performed to notify the multiple DSCs 144 of the auction results (e.g., they submitted winning bids, they have been defeated, they submitted losing bids, the auction is cancelled, etc.). In the example illustrated in fig. 12A through 12D, the DSAAP notification method 1200 is performed by a processing core in the DPC146 component and the DSC144 component, each of which may include all or part of a DSAAP module/component.

DSAAP notification method 1200 may be performed after DPC146 notifies DSC144 that a bid has been accepted (e.g., after operation 1106 illustrated in fig. 11). DSAAP notification method 1200 may also be performed after a bid time expires and/or in response to DPC146 detecting an event or situation (e.g., a new bid is received, a bid is over-bid, etc.).

In operation block 1202 shown in fig. 12A, the DPC146 may determine that the particular bid amount in the bid amount IE in the last, most recent, or most current bid request message accepted from the DSC144 is not the highest amount in the current bid. In operation 1204, DPC146 may generate and send a DSC bid over bid message to DSC144 to notify tenant DSC144 that its earlier bids were defeated by higher bids from other tenant DSCs and/or that their earlier bids are no longer valid. In various embodiments, the DPC146 may generate the DSC bid over-bid message to include any or all of the following: a message type Information Element (IE), a message ID IE, a cause IE, a bid message IE, a criticality diagnostic IE, a DSC ID IE, and a bid ID IE.

The DSC ID IE may include information suitable for identifying a particular tenant DSC 144. The bid ID IE may include a bid ID suitable for identifying a submitted bid that has been defeated. In operation block 1206, tenant DSC144 may perform various bid-over-bid failure response operations, such as by determining whether to submit a higher bid for the resource to that DPC146, submit a bid to a different DPC146, hang up an existing call to free up bandwidth, and so forth.

Referring to fig. 12B, in operation block 1210, DPC146 may determine that the bidding time has expired and that the particular bid amount in the bid amount IE in the last, most recent, or most current bid request message accepted from DSC144 is the highest amount in the current bid. In operation 1212, the DPC146 may generate and send a DSC bid winning message to the DSC144 to inform the tenant of the DSC144 that their earlier bids are winning bids. In various embodiments, the DPC146 may generate the DSC bid win message to include any or all of the following: a message type Information Element (IE), a message ID IE, a bid IDIE, a bid information IE, a DSC ID IE, and original bid details (e.g., bandwidth, MBPS, duration, and winning bid scalar, etc.). The DSC ID IE may include information suitable for identifying a particular tenant DSC 144. The bid ID IE may include a bid identifier suitable for identifying a bid to win the resource auction/bidding operation.

In operation block 1214, the winning tenant DSC144 may wait to receive a DSC resource allocated message from the DPC146 before scheduling its network devices and devices (e.g., wireless devices) to begin using and/or making resources available for use (i.e., scheduling the time at which the resources will be ready for use by the winning tenant's network). In operation block 1216, DPC146 may close the auction, such as by rejecting further bids from other networks for resources won by bids submitted by tenant DSC 144.

Referring to fig. 12C, in operation block 1220, DPC146 may determine that the bidding time has expired and that the particular bid amount in the bid amount IE in the last, most recent, or most current bid request message accepted from DSC144 is not the highest amount in the current bid. In operation 1222, the DPC146 may generate and send a DSC bid failure message to the DSC144 to notify the tenant DSC144 that its earlier bids did not win a bid and that the auction/bid was closed due to another tenant DSC winning an auction. In various embodiments, the DPC146 may generate a DSC bid failure message to include any or all of the following: a message type Information Element (IE), a message ID IE, a bid ID IE, and a DSC ID IE. The DSC ID IE may include information suitable for identifying the particular tenant DSC144 to which the failed bid was submitted and/or to which the DSC bid failure message was sent. The bid ID IE may include a bid identifier suitable for identifying a submitted bid.

In operation block 1224, tenant DSC144 may perform various failure response operations, such as determining whether to submit bids for other available resources, whether to hang up an existing call to free up resources, and so on. In operation block 1226, the DPC146 may close the auction and/or allow the failed tenant DSC to bid on other available resources.

Referring to fig. 12D, in operation block 1230, DPC146 may determine that the auction for the network resource previously submitted by DSC144 has been cancelled. For example, the DPC146 may determine that the lessor network operator has withdrawn the auction or that the DPC operator has withdrawn the auction for regulatory reasons. In operation 1232, the DPC146 may generate and send a DSC bid cancellation message to the DSC144 to notify the tenant that the DSC144 auction has been cancelled. In various embodiments, the DPC146 may generate the DSC bid cancellation message to include any or all of the following: a message type Information Element (IE), a message ID IE, a bid ID IE, a DSC ID IE, and a cause IE. The DSC ID IE may include information suitable for identifying a particular tenant DSC 144. The bid ID IE may include a bid identifier suitable for identifying the resource/bid for which the auction has been cancelled. The reason IE may include a reason code for cancellation of bids (e.g., bid revocation, bid cancellation, etc.). In operation block 1234, tenant DSC144 may perform various failure response operations, such as by determining whether to submit bids to different DPCs 146, hang up calls, etc.

Fig. 13A and 13B illustrate a DSAAP purchase method 1300 that allows a lessee network to make immediate (or nearly immediate) purchases and/or requires use of resources available for allocation by the lessor network. In the example illustrated in fig. 13A and 13B, the DSAAP purchase method 1300 is performed by a processing core in the DPC146 component and the DSC144 component, each of which may include all or part of a DSAAP module/component. In one embodiment, the DSC144 and DPC146 may be configured to perform the DSAAP method 1300 after the DSC144 retrieves/receives a list of resources available for purchase (e.g., after performing the DSAAP method 1000 discussed above with respect to fig. 10).

In operation block 1302 shown in fig. 13A and 13B, tenant DSC144 may identify and select a particular resource for immediate purchase from a list of resources (e.g., a list of resources obtained from performing DSAAP method 1000 discussed above). In various embodiments, the tenant DSC144 may select resources scheduled for a bid, currently being auctioned, available only for immediate purchase, etc. In operation 1304, the DSC144 may generate and send a DSC purchase request message to the DPC146 requesting purchase of the identified/selected resource from the lessor network.

In various embodiments, the DSC144 may generate a DSC purchase request message to include any or all of the following: a message type Information Element (IE), a message ID IE, a DSC identification IE, a DSC type IE, a bid ID IE, a purchase amount IE, and a PLMN ID IE. The PLMN ID IE may include information suitable for identifying a PLMN ID of a network associated with a bid that may be identified by the bid ID IE. The purchase amount IE may include the amount of bids (e.g., expressed in USD) submitted by tenant DSC144 (i.e., bid values).

In one embodiment, the DSC144 may be configured to generate a DSC purchase request message to include a purchase amount value equal to the amount identified by the purchase amount IE included in the list of bid IDs included in the received available bid response message (discussed above with reference to fig. 10).

In operation block 1306, shown in fig. 13A, the DPC146 may use the information included in the received DSC purchase request message to identify the following: the requested resource, the network associated with the requested resource, whether the requested resource is currently being auctioned, whether the requested resource is already available for immediate purchase, the minimum purchase amount requested for immediate purchase of the resource, and/or whether the purchase amount included in the received DSC purchase request message is equal to (or greater than) the requested purchase amount. In the example illustrated in fig. 13A, as part of operation block 1306, the DPC146 determines that the purchase amount included in the received DSC purchase request message is greater than or equal to the requested purchase amount.

In operation 1308, the DPC146 may generate and send a DSC purchase accept message to the DSC144 to notify the tenant DSC144 that it has successfully purchased/leased the resource for use. In various embodiments, the DPC146 may generate the DSC purchase accept message to include any or all of the following: a message type Information Element (IE), a message ID IE, and a bid ID IE. In operation block 1310, DPC146 may terminate, block, or close an active auction for the resource and/or perform similar operations, thereby making the resource no longer available for bidding or purchase by other tenant DSCs.

Referring to fig. 13B, in operation block 1312, the DPC146 may determine that bidding (purchase request) is to be denied using information included in the received DSC purchase request message (e.g., as part of operation 1304). For example, the DPC146 may determine that a particular purchase amount is less than the requested purchase amount in the purchase amount IE in the received DSC purchase request message. As another example, DPC146 may determine that the bid ID value included in the bid ID IE is invalid, or that the resource/bid is no longer available for bidding (due to expiration, auction end, bid revocation, invalid bid ID, etc.).

In operation 1314, the DPC146 may generate and send a DSC purchase denial message to the DSC 144. In various embodiments, the DPC146 may generate the DSC purchase denial message to include any or all of the following: a message type Information Element (IE), a message ID IE, a bid ID IE, and a cause IE. The value of the bid ID IE may be the same as the bid identifier included in the DSC purchase request message received as part of operation 1304. The reason IE may include a reason code that denies the purchase request (e.g., the requested purchase price is not met, no bids are found, etc.). In operation block 1316, the DSC1316 may perform various failure response operations, such as determining whether to submit a new purchase request with a higher bid amount. In operation block 1318, DPC146 performs various operations to make the resource available for bidding or purchase by other tenant DSCs.

Fig. 14A and 14B illustrate a DSAAP resource allocation method 1400 for allocating resources in a lessor network for access and use by multiple components in the lessee network. In the example illustrated in fig. 14A and 14B, the DSAAP resource allocation method 1400 is performed by processing cores in the DPC146 component, the tenant DSC144A component, and the tenant DSC144B component, each of which may include all or part of a DSAAP module/component.

In operation block 1402 shown in fig. 14A and 14B, the DPC146 may determine that the lessee DSC144A has successfully purchased or won an auction for a resource in the lessor network represented by the lessor DSC 144B. In operation 1404 shown in fig. 14A, the DPC146 may generate and send a DSC bid success message to the lessor DSC144b to inform the lessor network that one or more of its allocated resources/bids have been won by the lessee DSC 144A.

In various embodiments, the DPC146 may generate the DSC bid success message to include any or all of the following: a message type Information Element (IE), a message ID IE, a cause IE, and a criticality diagnosis IE. In further embodiments, the DPC146 may be configured to generate the DSC bid success message to further include any or all of the following: bid ID IE, DSC ID IE, and bid value IE. These additional information elements may be used to communicate information about winning bids. For example, the bid ID IE may include a bid ID corresponding to a bid that successfully participates in and wins an auction for the resource. The DSC ID IE may include the DSC ID of the auction winner (i.e., tenant DSC144 a). The bid value IE may include a winning bid amount and/or a purchase price of the resource.

In operation 1404, the lessor DSC144b may generate and send a DSC resource allocated message to the DPC146 to allocate/commit resources for access and use by multiple components in the lessee network. The lessor DSC144b may be configured to generate a DSC resource allocated message to include any or all of the following: message type Information Element (IE), message ID IE, bidding ID, PLMN-ID grid ID cell ID list IE, PLMN ID IE, grid ID IE, cell ID list IE, and various auction/resource details (e.g., bandwidth, MBPS, duration, etc.). In one embodiment, the PLMN ID IE, mesh ID IE and cell ID list IE may be included in the PLMN-ID mesh ID cell ID list IE. The PLMN ID IE may include the PLMN ID of the lessor network that allocated the resource, which may be the same PLMN ID/network identified in the winning bid. The mesh ID IE and cell ID list IE may include information suitable for identifying the mesh/cell associated with these resources. These values may be the same as the grid/cell values included in the winning bid.

In operation 1406, the DPC146 may forward the received DSC resource allocated message to the winning tenant DSC144a to cause the tenant DSC144a to begin using the allocated resources in the tenant network resources. In operation block 1408, the lessee DSC144a may schedule its own network device to begin using lessor network resources from a time specified as part of the bidding and/or included in the received DSC resource allocated message.

Referring to fig. 14B, in operation block 1410, the lessor DSC144B may determine that the submitted resources for the auction should be revoked and/or relinquish allocation of the submitted resources to the winner of the auction. After the DPC146 determines that the tenant network purchased or won the auction for the resources and/or for any of a variety of reasons (e.g., unforeseen reasons or administrative reasons, etc.), the lessor DSC144b may determine to revoke these resources.

In operation 1412, the lessor DSC144b may generate and send a DSC resource withdraw message to the DPC146 to withdraw the resource. The lessor DSC144b may generate a DSC resource withdrawal message to include any or all of the following: message type Information Element (IE), message ID IE, bid ID IE, cause IE, and PLMN-ID mesh ID cell ID list IE. The bid ID IE may include information suitable for identifying a bid. The reason IE may include a reason code describing the reason for revoking the resource allocation (e.g., resource unavailable, resource revoked, managed, etc.).

In operation 1414, the DPC146 may forward the received DSC resource withdrawal message to the tenant DSC144a, which may have submitted a winning bid for the withdrawn resource. In operation block 1416, the tenant DSC144a may perform various failure response operations, such as determining whether to participate in another auction, whether to bid on a different resource, whether to hang up the call to vacate the resource, and so on.

Fig. 15A and 15B illustrate an embodiment DSAAP back-off method 1500 for selectively switching a wireless device from a lessor network back to the network of the lessee to which the wireless device is subscribed (i.e., its home PLMN). In the example illustrated in fig. 15A and 15B, DSAAP back-off method 1500 is performed by processing cores in DPC146, tenant DSC144a, and tenant DSC144B components, each of which may include all or part of a DSAAP module/component.

In operation block 1502 shown in fig. 15A and 15B, the lessor DSC144B may determine that its network resources from a cell that was part of a previous auction are in congestion. That is, the lessor DSC144b may determine that it needs access to or use of its allocated resources. In operation 1504, the lessor DSC144b may generate and send a DSC backoff command message to the DPC146 to selectively switch back to the lessee network (i.e., its home PLMN) the one or more wireless devices that are using the allocated resources of the lessor network.

The lessor DSC144b may be configured to generate a DSC back-off command message to include any or all of the following: a message type Information Element (IE), a message ID IE, a bid ID IE, a UE identity IE, a measurement report IE, a cut-off cell information IE, a cause IE, and a DSC backoff response timer IE.

The UE identity IE may include information suitable for determining identity-related information for the wireless device (or UE), such as the International Mobile Subscriber Identity (IMSI) of the wireless device or its network.

The measurement report IE may include the latest, last, or most recent measurement report E-UTRAN RRC message received by the lessor network for the identified wireless device (i.e., the wireless device required to backoff to the lessee network).

The bid ID IE may include a bid ID value corresponding to a bid that successfully participated in and completed/won the auction. The bid ID can be used to identify the auctions/contracts associated with these back-off operations (i.e., the auctions/contracts for which resources are allocated).

In one embodiment, the lessor DSC144b may be configured to determine whether there are multiple bid IDs corresponding to congested cells. In one embodiment, in response to determining that there are multiple bid IDs corresponding to congested cells, the lessor DSC144b may be configured to select a bid ID value from the multiple bid IDs. In various embodiments, the lessor DSC144b may be configured to select a bid ID value based on operator policies provisioned at the lessor DSC144b, based on previous agreements, based on policies/rules previously negotiated by the lessor network and the lessee network, and so on.

In operation 1506, the DPC146 may forward the received DSC backoff command message to the tenant DSC144 a. In operation block 1508, the tenant DSC144a may use the information in the UE identity IE of the received DSC backoff command message to identify one or more wireless devices that are to undergo a backoff operation (i.e., wireless devices that are to be handed off back to).

In operation block 1510, the tenant DSC144a may use information included in the measurement report IE of the received DSC backoff command message to determine, identify, and/or select a target cell (within the tenant network) to which the identified one or more wireless devices are to be handed over (the tenant network may have previously enabled measurement reports from the wireless devices (as when they were attached or handed over to the tenant network).

In operation 1512, the tenant DSC144a may generate and send a DSC backoff response message to the DPC 146. The tenant DSC144a may be configured to generate a DSC backoff response message to include any or all of the following: a message type Information Element (IE), a message ID IE, a bid ID IE, a UE identity IE, a cell-of-cut information IE, and a cause IE. In one embodiment, in response to determining that a suitable target cell (within the tenant network) cannot be identified or selected for handover, the tenant DSC144a may be configured to generate a DSC backoff response message to include a cause IE (or a value of a cause IE). The value of the cause IE may identify the cause of the failure, such as network overload, failure to find a suitable target cell, or unknown wireless device/UE. In one embodiment, in response to successfully identifying a target cell (within the tenant network) to which the wireless device may be handed off, tenant DSC144a may be configured to generate a DSC backoff response message to include a value (e.g., target cell information) for the switch-off cell information IE.

In operation 1514, the DPC146 may identify the lessor DSC144a based on the bidding idIE included in the received DSC backoff response message and forward the received DSC backoff response message to the lessor DSC144 b. In operation block 1516, the lessor DSC144b may determine whether the received DSC backoff response message includes the detached cell information IE (or a valid value of the detached cell information IE). In response to determining that the received DSC backoff response message includes the cut-off cell information IE (or a valid value of the cut-off cell information IE), in operation block 1518, the lessor DSC144b may encode a handover required message using the target cell information included in the cut-off cell information IE. In operation block 1520, the lessor DSC144b may and initiates a handoff process based on S1 to handoff the wireless device from the lessor network to the lessee network.

Referring to fig. 15B, in operation block 1552, the lessor DSC144B may determine that the DPC146 has not responded to the DSC backoff command message (transmitted as part of operation 1504) within the time period identified in the DSC backoff response timer IE included in the DSC backoff command message. Alternatively or additionally, in operation block 1554, the lessor DSC144b may determine: there is significant or severe network congestion or a regulatory reason to revoke the allocation of all remaining network resources related to the resource/bid id included or identified in the DSC backoff command message.

In operation 1556, the tenant DSC144b may generate and send a DSC resource withdrawal message to the DPC 146. In operation 1558, the DPC146 may forward the received DSC resource withdrawal message to the tenant DSC144a to withdraw the allocation of the remaining network resources. In operation block 1560, tenant DSC144a may perform various resource withdrawal failure response operations, such as hanging up a call, determining whether to bid on a new resource, and so on.

Fig. 16A illustrates an embodiment DSC-initiated DSAAP deregistration method 1600 for termination operations. In the example illustrated in fig. 16A, the DSC-initiated DSAAP deregistration method 1600 is performed by a processing core in the DPC146 and DSC144 components, each of which may include all or part of a DSAAP module/component.

In operation block 1602, the DSC144 may determine that it needs to terminate DSA operations. In operation 1604, the DSC144 may generate a DSC deregistration message and send it to the DPC 146. The DSC144 may be configured to generate a DSC deregistration message to include any or all of the following: a message type Information Element (IE), a message ID IE, a back-off timer IE, and a reason IE identifying the reason for terminating these operations. In operation block 1606, in response to receiving the DSC deregistration message, the DPC146 may clear all relevant resources associated with the DSC144 and/or perform other similar operations to deregister the DSC 144.

Fig. 16B illustrates an embodiment DPC initiated DSAAP deregistration method 1650 for termination operations. In the example illustrated in fig. 16B, the DPC-initiated DSAAP deregistration method 1650 is performed by the processing cores in the DPC146 component and the DSC144 component, each of which may include all or part of the DSAAP module/component.

In operation block 1652, the DPC146 may determine that it needs to terminate DSA operations with the DSC 144. In operation 1654, the DPC146 may generate and send a DSC deregistration message to the DSC 144. The DPC146 may be configured to generate a DSC deregistration message to include any or all of the following: a message type Information Element (IE), a message ID IE, a backoff timer IE, and a cause IE identifying the reason for terminating these operations (e.g., overloaded, unspecified, etc.). In operation block 1656, the DPC146 may clear all relevant resources associated with the DSC144 and/or perform other similar operations to deregister the DSC 144.

In operation block 1658, the DSC144 may perform various deregistration failure response operations based on information included in the received DSC deregistration message. For example, when the value of the cause IE in the DSC deregistration message is set to "overloaded," the DSC144 may be configured not to retry registering with the same DPC146 for at least the duration indicated in the backoff timer IE included in the received DSC deregistration message.

Fig. 17A illustrates a DSC-initiated DSAAP error indication method 1700 for reporting errors, according to one embodiment. In the example illustrated in fig. 17A, method 1700 is performed by a processing core in a DPC146 component and a DSC144 component, each of which may include all or part of a DSAAP module/component.

In operation block 1702, the DSC144 may detect an error or error condition (e.g., protocol error, etc.). In operation 1704, the DSC144 may generate and send an error indication message to the DPC 146. DSC144 may be configured to generate an error indication message to include any or all of the following: a message type Information Element (IE), a message IDIE, a cause IE, and a criticality diagnosis IE. The cause IE may include information suitable for identifying a cause or type of error (e.g., transition syntax error, abstract syntax error, logical error, etc.). The criticality diagnosis IE may include a procedure code IE, a trigger message IE, and a procedure criticality IE. In operation block 1706, the DSC144 and/or DPC146 may perform various error response operations based on the detected error or information included in the received error indication message. Error detection and response operations are discussed in further detail below.

Figure 17B illustrates a DPC-initiated DSAAP error indication method 1750 for reporting errors, according to another embodiment. In the example illustrated in fig. 17B, method 1750 is performed by processing cores in DPC146 and DSC144 components, each of which may include all or part of a DSAAP module/component.

In operation block 1752, the DPC146 may detect an error condition. In operation 1754, the DPC146 may generate and send an error indication message to the DSC 144. The DPC146 may be configured to generate an error indication message to include a cause Information Element (IE) identifying a cause of the error. In operation block 1756, the DSC144 and/or DPC146 may perform various error response operations based on the information included in the received error indication message.

As described above, in response to detecting an error condition or a failure condition, the DSC144 and DPC146 may be configured to perform various error response operations or failure response operations. As part of these operations, the DSC144 and/or DPC146 may identify the type or cause of the error/failure condition and customize their response based on the identified type or cause. For example, the DSC144 and/or DPC146 may be configured to determine whether detected errors are protocol errors and customize their response accordingly.

Protocol errors include transfer syntax errors, abstract syntax errors, and logical errors. Transition syntax errors may occur when a receiving function DSAAP entity (e.g., DSC, DPC, etc.) is unable to decode a received physical message. For example, a transition syntax error may be detected when decoding the asn.1 information in the received message. In one embodiment, in response to determining that the detected error is a transition syntax error, the DSC144 component and DPC146 component may be configured to transmit or re-request DSAAP messages (e.g., as part of those error response operations).

Abstract syntax errors may occur when a receiving function DSAAP entity (e.g., DSC, DPC, etc.) receives an Information Element (IE) or a group of IEs (i.e., unknown IE ids) that cannot be understood or recognized. Abstract syntax errors may also occur when the entity receives an Information Element (IE) whose logical range (e.g., number of copies allowed) is violated. The DSC144 and DPC146 components may be configured to detect or identify these types of abstract syntax errors (i.e., abstract syntax errors that are unintelligible), and in response, perform error response operations based on critical information included in the corresponding DSAAP messages. Additional details regarding these operations and critical information are provided further below.

Abstract syntax errors may also occur when: the receiving function DSAAP entity does not receive the IEs or IE groups, but these IEs or IE groups should already be present in the received message according to the specified presence of the target. The DSC144 and DPC146 components may be configured to detect or identify these concrete types of abstract syntax errors (i.e., missing IEs or IE groups), and in response, perform error response operations based on the criticality information and presence information of the missing IEs/IE groups. Additional details regarding these operations, critical information, and presence information are provided further below.

Abstract syntax errors may also occur when the receiving entity receives IEs or groups of IEs that are defined in the wrong order as part of the message or that occur too many times in the same IE or group of IEs. Furthermore, abstract syntax errors may also occur when: the receiving entity receives the IEs or IE groups, but these IEs or IE groups should not already be present in the received message, depending on the conditional presence of the associated object and the specified conditions. The DSC144 component and DPC146 component may be configured to detect or identify such abstract syntax errors (i.e., error order, too many occurrences, erroneous presence, etc.), and in response, reject or terminate the process or method associated with the error (e.g., the method that caused the error). As part of the error response operation, the DSC144 component and DPC146 component may reject or terminate the process/method.

In various embodiments, the DSC144 component and DPC146 component may be configured to continue decoding, reading, or processing DSAAP messages after detecting, identifying, or determining that an abstract syntax error occurred for the message. For example, the DSC144 component and DPC146 component may skip portions of the message that include errors and continue processing other portions of the message. As part of this continued processing, the DSC144 component and DPC146 component may detect or identify additional abstract syntax errors.

In one embodiment, the DSC144 component and DPC146 component may be configured to perform multiple error response operations for each detected abstract syntax error and/or based on criticality information and presence information of the IE/IE group associated with the abstract syntax error.

As described above, each DSAAP message may include or may be associated with criticality information, presence information, scope information, and assigned criticality information. In various embodiments, a receiving function DSAAP entity (e.g., DSC, DPC, etc.) may be configured to use any or all of such information (e.g., criticality information, presence information, etc.) in detecting errors, identifying error types, or specific error responses to be performed. That is, the entity may perform different operations depending on the criticality information, presence information, scope information, and/or the value of the assigned criticality information.

In one embodiment, upon identifying an error type and a particular error response operation to be performed for the identified error type, the receiving function DSAAP entity (e.g., DSC, DPC, etc.) may be configured to use the presence information included in the DSAAP message. For example, the entity may use the presence information to determine whether the presence of an Information Element (IE) is optional, conditional, or mandatory (e.g., with respect to RNS applications) for the message or communication. When a received message misses one or more cells that are determined to be mandatory (or conditional when the condition is true), the entity may determine that an abstract syntax error has occurred.

In one embodiment, the receiving function DSAAP entity (e.g., DSC, DPC, etc.) may be configured to use the criticality information in identifying the particular error response operation to be performed. That is, each DSAAP message may include criticality information for each Information Element (IE) or group of IEs included in the message. The values of criticality information for each IE or group of IEs may include "reject IE", "ignore IE and notify sender", and "ignore IE". The receiving entity (e.g., DSC, DPC, etc.) may use this critical information to determine that the IE, IE group, or EP is not intelligible, identify this as an abstract syntax error (i.e., an unintelligible abstract syntax error) and/or identify those error response operations that are to be performed (e.g., reject, ignore, notify, etc.).

In one embodiment, in response to determining that an Information Element (IE) included in a message received during execution of a method/process is unintelligible and that the value of critical information for the IE is set to "reject IE," a receiving entity (e.g., DSC, DPC, etc.) may be configured to reject the method/process and initiate a DSAAP error indication method (discussed above with reference to fig. 17A-B).

For example, when a message is received that initiates a method/process (e.g., a DSC register request message, etc.) and it is determined that the message includes one or more IEs/IE groups that are incomprehensible and labeled "reject IEs," the receiving entity may reject the method/process by not performing any of the function requests included in the message. The receiving entity may also report rejection of one or more IEs/IE groups using messages that are typically used to report unsuccessful results of the procedure. When the information in the received initiation message is insufficient and cannot be used to determine the values of all IEs that need to be present in the message for reporting the unsuccessful outcome of the procedure, the receiving entity may terminate the procedure and initiate the DSAAP error indication method/procedure.

As a further example, when a message is received that initiates a method/process (which does not have a message to report an unsuccessful result) and that message includes one or more IEs/IE groups marked with a "reject IE" that the receiving entity does not understand, the receiving entity may terminate the method/process and initiate a DSAAP error indication method/process.

As yet another example, when a response message (e.g., a DSC register response message, etc.) is received that includes one or more IEs tagged with "reject IEs" that the receiving entity does not understand, the receiving entity may consider the method/process to have not successfully terminated and initiate a local error handling method.

In one embodiment, in response to determining that an Information Element (IE) included in a message received during execution of a method/process is unintelligible and that the value of critical information for the IE is set to "ignore IE and notify sender," a receiving entity (e.g., DSC, DPC, etc.) may be configured to ignore or skip the method/process and initiate a DSAAP error indication method (discussed above with reference to fig. 17A-B).

As an example, upon receiving a message initiating a method/procedure containing one or more IE/IE groups that the receiving entity does not understand to "ignore IEs and notify sender" flags, the receiving entity may ignore the contents of these unintelligible IE/IE groups, proceed with the method/procedure using the understood IE/IE groups as if the unintelligible IE/IE groups were not received (except for reporting), and report in a response message to the method/procedure that one or more IE/IE groups have been ignored. When the information received in the initiation message is not sufficient to determine the values of all IEs that need to be present in the response message, the receiving entity may terminate the method/procedure and initiate a DSAAP error indication method/procedure.

As a further example, upon receiving a message that initiates a method/process (which has no message to report the result of the method/process) containing one or more IEs/IE groups that the receiving entity does not understand to flag "ignore IEs and notify sender", the receiving entity may ignore the contents of these unintelligible IEs/IE groups, continue to use the understood IEs/IE groups for the method/process as if these unintelligible IEs/IE groups were not received (except for reporting), and initiate a DSAAP error indication method/process to report that one or more IE/IE groups have been ignored.

As yet another example, upon receiving a response message containing one or more IEs/IE groups that the receiving entity does not understand to flag "ignore IEs and notify sender," the receiving entity may ignore the contents of these unintelligible IEs/IE groups, continue to use (other than report) the understood IEs/IE groups for the method/process as if these unintelligible IEs/IE groups were not received, and initiate a DSAAP error indication method/process.

In one embodiment, in response to determining that an Information Element (IE) included in a message received during execution of a method/process is unintelligible and that a value of critical information for the IE is set to an "ignore IE," a receiving entity (e.g., DSC, DPC, etc.) may be configured to ignore or skip the method/process.

As one example, upon receiving a message initiating a method/procedure that contains one or more IEs/IE groups marked with an "ignore IE" that the receiving entity does not understand, the receiving entity may ignore the contents of these unintelligible IEs/IE groups and proceed to do so using only the understood IEs/IE groups as if the unintelligible IEs/IE groups were not received.

As a further example, upon receiving a response message containing one or more IEs/IE groups marked with "ignore IEs" that the receiving entity does not understand, the receiving entity may ignore the contents of these unintelligible IEs/IE groups and proceed to use the understood IEs/IE groups for the method/process as if the unintelligible IEs/IE groups were not received.

When multiple, unintelligible IE/IE groups marked with "reject IE" or "ignore IE and notify sender" are reported using a response message defined for the method/procedure, an information element critical diagnostic IE may be included in the critical diagnostic IE for each reported IE/IE group.

In one embodiment, in response to determining that the receiving entity is unable to decode the message type IE in the received message, the receiving entity (e.g., DSC, DPC, etc.) may be configured to initiate a DSAAP error indication method (discussed above with respect to fig. 17A-B). In one embodiment, in determining the correct order of IEs included in a message, the entity may be configured to consider only those IEs specified in the version of the specification used by the component.

In one embodiment, the receiving entity (e.g., DSC, DPC, etc.) may be configured to process the missing IE/IE group in accordance with the criticality information of the missing IE/IE group in the received message as specified in the version of the present document used by the receiving party.

As an example, in response to determining that one or more IEs/IE groups with a specified critical "reject IE" are missing from the received origination message, the receiving entity (e.g., DSC, DPC, etc.) may be configured to not execute any of those function requests of the received message. The receiving entity may reject the method/procedure and report the missing IE/IE group using a message that is typically used to report unsuccessful results of the method/procedure. When it is determined that the information received in the initiation message is insufficient to determine the values of all IEs that need to be present in the message for reporting unsuccessful results of the method/process, the receiving entity may terminate the method/process and initiate the DSAAP error indication method/process.

As a further example, when a received message initiating a method/process (which has no message to report an unsuccessful result) misses one or more IE/IE groups with a specified critical "reject IE", the receiving entity may terminate the method/process and initiate a DSAAP error indication method/process.

As yet another example, when a received response message misses one or more IEs/IE groups with a specified critical "reject IE," the receiving entity may consider the method/process to have not been successfully terminated and initiate a local error handling method/process.

As another example, when a received message initiating a method/procedure loses one or more IE/IE groups with a specified criticality of "ignore IE and notify sender", the receiving entity may ignore those IE losses and proceed with the method/procedure based on other IE/IE groups present in the message and report in a response message to the method/procedure that one or more IE/IE groups are lost. When the information received in the initiation message is not sufficient to determine the values of all IEs that need to be present in the response message, the receiving entity may terminate the method/procedure and initiate a DSAAP error indication method/procedure.

As another example, when a received message initiating a method/process (which has no message to report the result of the method/process) loses one or more IEs/IE groups with a specified critical "ignore IE and notify sender", the receiving entity may ignore those IE losses and proceed with the method/process based on other IE/IE groups present in the message and initiate a DSAAP error indication method/process to report the loss of one or more IE/IE groups.

As another example, when a response message received by the received message loses one or more IE/IE groups with a designated criticality of "ignore IE and notify sender", the receiving entity may ignore those IE losses and proceed with the method/process based on other IE/IE groups present in the message and initiate a DSAAP error indication method/process to report the loss of one or more IE/IE groups.

As another example, when a received message initiating a method/procedure loses one or more IE/IE groups with a designated critical "ignore IE," the receiving entity may ignore those IE losses and proceed with the method/procedure based on other IE/IE groups present in the message.

As another example, when a received response message misses one or more IE/IE groups with a specified critical "ignore IE," the receiving entity may ignore those IE/IE group misses and proceed with the method/procedure based on other IE/IE groups present in the message.

The receiving entity (e.g., DSC, DPC, etc.) may be configured to respond to multiple messages that include IEs or groups of IEs received in the wrong order, include too many occurrences, or are erroneously present in various ways (i.e., included and marked as "conditional" when conditions are not met). For example, in response to determining that the received message includes an IE or group of IEs with an incorrect order, includes too many occurrences of IEs, or includes an erroneously existing IE, the receiving entity (e.g., DSC, DPC, etc.) may be configured to not perform any of those function requests of the received message. The receiving entity may reject the method/process and report a cause value of "abstract syntax error" (incorrectly constructed message) using a message that is typically used to report unsuccessful results of the method/process. When the information received in the initiation message is insufficient to determine the values of all IEs that need to be present in the message for reporting unsuccessful results of the method/process, the receiving entity may terminate the method/process and initiate the DSAAP error indication method/process.

As another example, when a message is received that initiates a method/process (which has no message to report the result of the method/process) that contains one or more IEs or IE groups that have an incorrect order or that have too many occurrences or are present incorrectly, the receiving entity may terminate the method/process and initiate a DSAAP error indication method/process using a cause value "abstract syntax error" (incorrectly constructed message).

As another example, when a response message is received containing one or more IEs or groups of IEs that have an incorrect order or that have too many occurrences or are present in error, the receiving entity may assume that the method/process was unsuccessfully terminated and initiate local error handling.

As described above, the protocol errors include transfer syntax errors, abstract syntax errors, and logical errors. A logic error occurs when: the message is properly understood, but the information contained within the message is invalid (i.e., a semantic error), or describes a method/process that is incompatible with the state of the receiving entity.

In one embodiment, in response to determining/detecting a logical error, the receiving entity (e.g., DSC, DPC, etc.) may be configured to perform various error response operations based on the category of the method/process without regard to the criticality information of those IEs/IE groups that contain error values.

For example, when a logical error is detected in the request message for a category 1 method/process and the method/process has a message to report this unsuccessful result, this message may be sent with an appropriate cause value (i.e., in a cause IE), such as "semantic error" or "message is not compatible with the recipient status". When a logical error is detected in the request message of a class 1 method/process and the method/process does not have a message to report this unsuccessful result, the method/process may be terminated and the DSAAP error indication method/process initiated with the appropriate cause value. When a logical error is present in the response message of the category 1 procedure, the procedure may be deemed to have not been successfully terminated and local error handling may be initiated.

When a logical error is detected in the message of the class 2 procedure, the procedure may be terminated and the DSAAP error indication procedure may be initiated with an appropriate cause value.

In various embodiments, when a protocol error is detected in the error indication message, the receiving entity (e.g., DSC, DPC, etc.) may be configured to perform a local error handling method/procedure (as opposed to a DSAAP error indication method/procedure). If a response message or error indication message needs to be returned, but the information needed to determine the recipient of the message is lost, the process may be considered to have not been successfully terminated and local error handling may be initiated. When an error occurs that terminates a process, the returned cause value may reflect the error that caused the process to terminate, even though one or more abstract syntax errors with critical "ignore and notify" have occurred earlier within the same process.

Fig. 18A illustrates an embodiment HSS subscriber profile management method 1800 for updating information stored in or managed by MME 130. HSS user profile management method 1800 may be performed by processing cores in the HSS 130 component and the MME130 component, each of which may include all or part of the DSAAP modules/components.

In operation block 1802, HSS132 may monitor the HSS user profile repository to determine whether HSS information (or HSS user profile information) has changed for the wireless device (or for a wireless device user/subscriber). In the example illustrated in fig. 18A, the HSS132 detects that the HSS information has changed in block 1802. In operation block 1804, HSS132 may determine whether the detected change affects an HSS user profile stored in MME130 associated with the wireless device. For example, HSS132 may determine: whether the changed HSS information identifies a new QoS level to be provided to the wireless device, whether the wireless device is allowed to use resources in the lessor network (e.g., via the lessee network winning the bid), etc.

In operation 1806, in response to determining that the detected change affects MME130, HSS132 may generate and send an HSS insert subscriber data communication message to MME 130. HSS132 may generate the HSS insert subscriber data message to include information suitable for notifying MME130 of those changes to the HSS information, such as an IMSI value and changed subscription information/data. In one embodiment, the HSS insert subscriber data message may be a "changed data" communication message.

In operation block 1808, the MME130 may receive the HSS insert subscriber data message and add, remove, or modify stored user profile information of the MME130 using information included in the received message. In operation block 1812, the MME processing core may perform a number of additional operations to initiate appropriate actions, if necessary, in response to these changes. For example, in operation block 1812, MME130 may initiate a disconnect procedure in response to determining that the wireless device is not allowed to roam in the network based on information included in the HSS insert subscriber data. No further operations may be required in block 1812 for the received PDN subscription context without a related active PDN connection in the MME 130. Otherwise, if the subscription QoS profile has been modified and the wireless device is in an ECM-connected state or in an ECM-idle state when the ISR is not activated, an HSS-initiated subscription QoS modification procedure/method may be invoked or executed in block 1812. If the wireless device is in ECM-idle state and ISR is activated, MME130 may invoke or execute the HSS-initiated subscription QoS modification procedure/method the next time the ECM-idle to ECM-connection transitions. If the wireless device is in ECM-idle state and ISR is not activated (and if the subscription changes no longer allows PDN connections), MME130 may initiate a PDN disconnection procedure to delete the relevant PDN connection. If the wireless device is in an ECM-connected state and connected through a CSG or hybrid cell, the MME130 may check the received CSG subscription data to determine if the CSG membership of the cell has changed or expired. If the MME130 detects that the membership of the cell has changed or expired, the MME130 may perform various operations to respond accordingly.

In operation 1812, MME130 may generate and send an HSS insert subscriber data confirm message to HSS 132. MME130 may generate the HSS insert subscriber data confirm message to include the IMSI value and information and/or the result of additional operations appropriate to inform MME130 of those changes to the user profile information. In operation block 1812, the HSS processing core may receive the HSS insert subscriber data confirm message and update its information to match MME130 using information included in the received message.

FIG. 18B illustrates an embodiment method 1850 of clearing information. The method 1850 may be performed by processing cores in the HSS 130 component and the MME130 component, each of which may include all or part of the DSAAP modules/components.

In operation block 1852, the MME130 may determine whether the subscription data and mobility management context information for the disconnected wireless device have been deleted and delete the user profile information and subscription data corresponding to the disconnected wireless device. MME130 may delete the subscription data and mobility management context information immediately after an implicit or explicit disconnection, or maintain the information for a preset period of time, so that the data may be reused at a later time of attachment without requiring access to HSS 132.

In operation 1854, the MME130 may generate and send a clear UE communication message to the HSS 132. In operation block 1856, the HSS132 may update its information and record to reflect that the wireless device has been disconnected. For example, HSS132 may set a "clear UE for E-UTRAN" flag. In operation 1858, the HSS132 may generate and send a clear UE acknowledgement message to the MME 130.

Fig. 18C shows an embodiment method 1870 of requesting subscriber data from a Home Subscriber Server (HSS). The method 1870 may be performed by processing cores in the HSS 130 component and the DSC 1144 component, each of which may include all or part of a DSAAP module/component.

In operation block 1854, the DSC144 may be performing resource allocation operations for DSA leases (e.g., for winning bids that allow a tenant network to use resources of the lessor network). In operation block 1874, the DSC144 may obtain a network identifier or PLMN for the lease (e.g., identified in the winning bid) and initiate a query to the tenant HSS 132. In operation 1876, the DSC144 may generate and send a subscriber data request message to the HSS132 component.

In operation block 1878, the HSS132 may use the information included in the received subscriber data request message to identify and select wireless device subscribers that are allowed to use the lessor resources under the DSA lease, along with their user profile information (e.g., QoS or service bundle definition information). Further, HSS132 may update the user profile information using information included in the received subscriber data request message, if necessary. In operation 1880, the HSS132 may generate and send a subscriber data response message to the DSC144 component. In various embodiments, HSS132 may generate the subscriber data response message to include information about the location of the wireless device, an IP address, a QoS profile, access restrictions for roaming, a PDN to which the wireless device is allowed to connect, an APN address or PDN address indicating an IP address of one or more subscriptions, an identity of an MME to which the wireless device is currently attached or registered, and so on.

Fig. 19 illustrates an embodiment HSS method 1900 of updating user profile information in a Mobility Management Entity (MME). Method 1900 may be performed in a processing core of a HSS component.

In block 1902, the processing core may receive user profile information, subscriber data, wireless device information, and/or DSA information from the DSC. For example, the processing core may receive updated information regarding the location of the wireless device, an IP address, a QoS profile, access restrictions for roaming, a PDN to which the wireless device is allowed to connect, an APN address or PDN address indicating an IP address of one or more subscriptions, an identification of an MME to which the wireless device is currently attached or registered, and so forth. Also, in block 1902, the processing core may determine: whether any HSS information stored in the memory of the HSS component should be updated in view of the information received from the DSC component.

In block 1904, the processing core may determine whether HSS information (e.g., HSS user profile information) stored in the memory of the HSS has changed for the wireless device (e.g., in response to receiving updated information from the DSC). In various embodiments, the HSS information may include: user profile information, subscription information, wireless device location information, IP address information, QoS profile information, access restrictions for roaming, PDNs to which the wireless device is allowed to connect, APN or PDN addresses indicating one or more subscribed IP addresses, identities of MMEs to which the wireless device is currently attached or registered, International Mobile Subscriber Identity (IMSI) values, Network Access Mode (NAM) values, International Mobile Equipment Identity (IMEI), wireless device type identifiers, data related to authentication and encryption, data related to roaming permissions, wireless device status information, data related to operator-determined restrictions, tracking information, privacy exception lists, service type information, charging information, and/or any information typically stored by a HSS component and/or subscriber profile repository.

In block 1906, the processing core may determine whether those changes to the HSS information affect information stored in the user profile repository of the MME. In block 1908, the processing core may generate a changed data communication message that includes information identifying those changes to the HSS information stored in the memory of the HSS. In block 1910, the processing core may send the generated changed data communication message to the MME via the first communication link.

Fig. 20 illustrates an embodiment MME method 2000 for updating user profile information and modifying quality of service (QoS) of a wireless device. The method 2000 may be performed in a processing core of an MME component. In block 2002, the processing core may receive the altered data communication message from the HSS component. In block 2004, the processing core may modify user profile information stored in a user profile repository of the MME using information included in the received changed data communication message. In block 2006, the processing core may use information included in the received changed data communication message to determine whether a Public Data Network (PDN) subscription context has an associated active PDN connection in the MME. In block 2008, the processing core may use information included in the received changed data communication message to determine whether a subscription quality of service (QoS) profile has been modified.

In block 2010, in response to determining that the QoS profile has been modified, the processing core may perform a plurality of subscription QoS modification operations. Performing the subscription QoS modification procedure/method may include performing various operations to increase or decrease the QoS provided to the user group or wireless device (e.g., downgrade the QoS of the data connection to reduce congestion at the eNodeB) and/or update the QoS information stored or managed by the MME component or the HSS component. In one embodiment, in block 2010, in response to determining that the subscription QoS profile has been modified, the wireless device is in one of an ECM-connected state or an ECM-idle state, and/or the ISR has not been activated, the processing core may initiate a QoS modification process/method. In a further embodiment, in block 2010, in response to determining that the wireless device is in an ECM-idle state and the ISR has been activated, the processing core may initiate (or cause the HSS component to initiate) a subscription QoS modification procedure/method after the next ECM-idle-to-ECM-connection transition.

Various embodiments may include or use Dynamic Spectrum Arbitration Application Part (DSAAP) protocols and/or components configured to allow, facilitate, support, or enhance communication between two or more DSA components (e.g., DPC, DSC, eNodeB, MME, HSS, etc.) in order to improve the efficiency and speed of DSA systems. The DSA component may be any component discussed in this application and/or any component participating in any DSA operation, communication, or method discussed in this application. Thus, one or more DSAAP components may be configured to allow, facilitate, support, or enhance communication between any of the components discussed herein, including communication between a DPC component and a DSC component, a DSC component and an eNodeB component, a DSC component and an MME component, a DSC component and an HSS component, an MME component and an HSS component, an eNodeB component and a wireless device, and so forth.

To facilitate communication between two or more DSA components, the DSAAP component may publish an Application Programming Interface (API) and/or include a plurality of client modules that facilitate communication between the DSA components. Additionally, the DSAAP components may be configured to allow the DSA components to communicate specific information, use specific communication messages, and/or perform specific operations that together provide various DSA functions that further improve the efficiency and speed of the DSA system and participating networks.

As one example, the DSAAP components may be configured to allow the eNodeB to communicate with the DSC component (e.g., over the Xe interface), with other enodebs (e.g., over the X2 interface), and with various other components (e.g., over the S1 interface). As a further example, the DSAAP component may be configured to allow, facilitate, support, or enhance communication between the DSC component and the DPC component in order to allow the DPC component and/or DSC component to pool resources across different better networks, better monitor traffic and resource usage in the various networks, more efficiently communicate bid and bid information, quickly and efficiently register and deregister components, and better perform backoff operations. The DSAAP component may also improve DSA resource auction operations by improving the performance and efficiency of the processes of bidding, generating invoices, advertising resources, requesting resources, purchasing resources, validating bidding credentials, and the like.

In various embodiments, all or portions of the DSAAP components may be included in one or more DSA components, such as a DPC component, a DSC component, an eNodeB component, an MME component, and an HSS component. The DSAAP components may be implemented in hardware, software, or a combination of hardware and software. In one embodiment, the DSAAP component may be configured to implement a DSAAP protocol, which may be defined over Xe, Xd, and/or X2 reference points. In various embodiments, the Xe reference point between DSC and eNodeB may use the DSAAP protocol, TR-069 protocol, and/or TR-192 data model extensions to support listing available resources at the eNodeB and informing the eNodeB of bidding/purchase confirmation. The Xd reference point between DSC and DPC may use the DSAAP protocol for dynamic spectrum and resource arbitration operations. The X2 interface/reference point between these enodebs may also communicate information using the DSAAP protocol.

In various embodiments, the DSAAP components may be configured to allow various DSA components (e.g., DSCs, DPCs, enodebs, etc.) to communicate using DSAAP protocols and/or to perform various DSAAP methods. The DSAAP method may be performed in any of the DSA systems discussed in this application, such as a system that includes a first DSC server in a first telecommunications network (e.g., a tenant network), a second DSC server in a second telecommunications network (e.g., a lessor network), and a DPC server outside of the first and second telecommunications networks.

The various embodiments may be implemented on a variety of mobile wireless computing devices, an example of which is illustrated in fig. 21. Specifically, fig. 21 is a system block diagram of a mobile transceiver device in the form of a smart phone/cellular phone 2100 suitable for use with any of the embodiments. The cellular telephone 2100 may include a processor 2101 coupled to internal memory 2102, a display 2103, and speakers 2104. Additionally, the cellular telephone 2100 may include an antenna 2105 for sending and receiving electromagnetic radiation that may be connected to a wireless data link and/or cellular telephone transceiver 2106 coupled to the processor 2101. The cellular telephone 2100 also typically includes a menu selection button or toggle switch 2107 for receiving user inputs.

The typical cellular telephone 2100 also includes a voice encode/decode (CODEC) circuit 2108 that digitizes voice received from the microphone into data packets suitable for wireless communication and decodes the received voice data packets to generate analog signals, which are provided to a speaker 2104 to generate the voice. Likewise, one or more of the processor 2101, wireless transceiver 2106, and CODEC 2108 may comprise a Digital Signal Processor (DSP) circuit (not separately shown). The cellular telephone 2100 may further include a ZigBee receiver (i.e., an IEEE 802.15.4 receiver) or other similar communication circuit (e.g., implementing) for low-power short-range communication between wireless devicesOr circuitry of WiFi protocol, etc.).

The above-described embodiments including the spectrum arbitration function are implemented on a variety of commercially available server devices within a broadcast system, such as the server 2200 shown in fig. 22. Such a server 2200 typically includes a processor 2201 connected to volatile memory 2202 and a large capacity non-volatile memory, such as a disk drive 2203. The server 2200 may also include a floppy disk drive, Compact Disk (CD) or DVD disk drive 2204 coupled to the processor 2201. The server 2200 can also include a network access port 2206 coupled to the processor 2201 for establishing a data connection with a network 2207, such as a local area network coupled to other communication system computers and servers.

The processors 2101, 2201 may be any programmable microprocessor, or multiple processor chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described below. In some wireless devices, multiple processors 2201 may be provided, such as a processor dedicated to wireless communication functions and a processor dedicated to running other applications. Typically, software applications may be stored in the internal memory 2102, 2202 before they are accessed and loaded into the processor 2101, 2201. The processors 2101, 2201 may include internal memory sufficient to store the application software instructions. In some servers, the processor 2201 may include internal memory sufficient to store the application software instructions. In some receiver devices, the secure memory may be a separate memory chip coupled to the processor 2101. The internal memory 2102, 2202 may be volatile or non-volatile memory (e.g., flash memory), or a mixture of both. For purposes of this description, a general reference to memory refers to all memory accessible to the processors 2101, 2201, including internal memory 2102, 2202; a removable memory inserted into the device; and memory within the processors 2101, 2201 themselves.

The foregoing method descriptions and process flow diagrams are provided as illustrative examples and are not intended to require or imply that the steps of the various embodiments must be performed in the order presented. As one of ordinary skill in the art will appreciate, the order of the steps in the foregoing embodiments may be performed in any order. Words such as "thereafter," "then," "next," etc. are not intended to limit the order of the steps; these words are used only to guide the reader through the description of the method. Furthermore, any reference to an element in the singular (e.g., using the articles "a," "an," or "the") should not be construed as limiting the element to the singular.

The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DPC), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microprocessor, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DPC and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DPC core, or any other such configuration. Alternatively, some steps or methods may be performed by circuitry that is dedicated to a given function.

In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable medium or a non-transitory processor-readable medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module, which may be present on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium that is accessible to a computer or processor. By way of example, and not limitation, non-transitory computer-readable or processor-readable media can comprise RAM, ROM, EEPROM, flash memory, CD-ROM, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, includes Compact Disc (CD), laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and memory-readable media. Further, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory memory readable medium and/or computer readable medium, which may be incorporated into a computer program product.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the scope of the disclosure. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles disclosed herein.

Claims (16)

1. A dynamic spectrum arbitrage, DSA, system comprising:

a home subscriber server, HSS, comprising an HSS processor;

a Mobility Management Entity (MME) comprising an MME processor coupled to the HSS via a first communication link;

an eNodeB comprising an eNodeB processor coupled to the MME via a second communication link;

a dynamic spectrum controller, DSC, comprising a DSC processor coupled to the eNodeB via a third communication link; and

a dynamic spectrum policy controller (DPC) comprising a DPC processor coupled to the DSC via a fourth communication link,

wherein the HSS processor is configured with processor-executable instructions to perform operations comprising:

determining whether HSS information stored in a memory of the HSS has changed for a wireless device;

in response to determining that the HSS information has changed, determining whether the changes affect user profile information stored in a user profile repository of the MME;

generating a modified data communication message including information identifying the modifications; and

sending the generated varied data communication message to the MME via the first communication link, and wherein the MME processor is configured with processor-executable instructions to perform operations comprising:

receiving the altered data communication message via the first communication link;

using information included in the received changed data communication message to determine whether a Public Data Network (PDN) subscription context has an associated active PDN connection in the MME;

determining whether a subscription quality of service (QoS) profile has been modified; and

a subscription QoS modification operation is performed.

2. The DSA system of claim 1, wherein the MME processor is configured with processor-executable instructions to perform operations comprising:

adding user profile information included in the received changed data communication message to the user profile repository.

3. The DSA system of claim 1, wherein the MME processor is configured with processor-executable instructions to perform operations comprising:

modifying the user profile information stored in the user profile repository using information included in the received altered data communication message.

4. The DSA system of claim 1, wherein the MME processor is configured with processor-executable instructions to perform operations comprising:

determining whether subscription data and a mobility management context of a disconnected radio have been deleted; and

sending a clear communication message to the HSS via the first communication link in response to determining that the subscription data and the mobility management context for the disconnected wireless have been deleted.

5. The DSA system of claim 4, wherein the HSS processor is configured with processor-executable instructions to perform operations comprising:

receiving the clear communication message via the first communication link; and

a clear flag is set in response to receiving the clear communication message.

6. The DSA system of claim 1, wherein the DPC processor is configured with processor-executable instructions to perform operations comprising:

receiving a resource withdrawal communication message from a second DSC indicating that a resource submitted for an auction should be withdrawn from the auction; and

transmitting the received resource withdrawal communication message to the DSC via the fourth communication link.

7. The DSA system of claim 6, wherein the DSC processor is configured with processor-executable instructions to perform operations comprising:

receiving the resource withdrawal communication message from the DPC via the fourth communication link; and

sending a request to the eNodeB via the third communication link to delete a closed subscriber group identifier associated with the indicated resource.

8. The DSA system of claim 7, wherein the eNodeB processor is configured with processor-executable instructions to perform operations comprising:

receiving the request to delete the closed subscriber group identifier from the DSC via the third communication link;

updating an active resource list by removing the closed subscriber group identifier from the active resource list;

generating a configuration update communication message, the configuration update communication message including the updated list of active resources; and

sending the configuration update communication message to the MME via the second communication link.

9. The DSA system of claim 1, wherein:

the DSC processor is coupled to the HSS via a fifth communication link; and

the DSC processor is coupled to the MME via a sixth communication link.

10. The DSA system of claim 9, wherein the HSS processor is configured with processor-executable instructions to perform operations comprising:

receiving updated HSS information from the DSC via the fifth communication link; and

determining whether the updated HSS information affects user profile information stored in the user profile repository of the MME.

11. A Dynamic Spectrum Arbitrage (DSA) method for synchronizing information comprises the following steps:

determining, in a processor of a home subscriber server, HSS, whether HSS information stored in a memory of the HSS has changed for a wireless device;

in response to determining that the HSS information has changed, determining whether the changes affect subscriber profile information stored in a subscriber profile repository of a mobility management entity, MME;

generating a modified data communication message including information identifying the modifications;

sending the generated changed data communication message to the MME;

receiving the changed data communication message in an MME processor of the MME;

using information included in the received changed data communication message to determine whether a Public Data Network (PDN) subscription context has an associated active PDN connection in the MME;

the MME processor determining whether a subscription quality of service, QoS, profile has been modified; and

in response to determining that the subscribed QoS profile has been modified, the MME processor performs a subscribed QoS modification operation.

12. The DSA method of claim 11, further comprising:

adding user profile information included in the received changed data communication message to the user profile repository of the MME.

13. The DSA method of claim 11, further comprising:

modifying user profile information stored in the user profile repository of the MME using information included in the received changed data communication message.

14. A home subscriber server, HSS, comprising;

a memory; and

a processor coupled to the memory, wherein the processor is configured with processor-executable instructions to perform operations comprising:

establishing a first communication link to a mobility management entity, MME, server;

determining whether HSS information stored in the memory has changed for a wireless device;

in response to determining that the HSS information has changed, determining whether the changes affect user profile information stored in a user profile repository of the MME;

generating a changed data communication message including information identifying the changes, including information for determining whether a subscription quality of service (QoS) profile has been modified for the wireless device; and

sending the generated altered data communication message to the MME via the first communication link.

15. The HSS of claim 14, wherein the processor is configured with processor-executable instructions to perform operations further comprising:

establishing a second communication link to a dynamic spectrum controller, DSC, server;

receiving a subscriber information request from the DSC via the second communication link; and

sending the HSS information to the DSC in response to receiving the request.

16. The HSS of claim 14, wherein the processor is configured with processor-executable instructions to perform operations such that generating the changed data communication message comprises generating the changed data communication message to include information for determining whether a public data network, PDN, subscription context has an associated active PDN connection in the MME.