Patent Application
20220191772
This disclosure is directed to core network identity and capability dissemination to wireless terminal devices from a radio access network node shared by multiple non-public and/or public core networks.
The carrier network portion of a wireless communication system may include geographically distributed radio access networks for providing over-the-air access to fixed or mobile wireless terminal devices, and core networks for routing data traffic among radio access networks or between radio access networks and other data networks external to the core networks. The wireless access networks may be connected to the core networks via wired backhaul connections. The radio access networks may rely on cellular technologies to reuse radio resources and may include a plurality of wireless access network nodes. A radio access network node may be connected to and shared by multiple core networks. These core networks may include both public and non-public core networks. Each core network may be identified by a unique network ID or a unique combination of network IDs. A wireless terminal device may be preconfigured with capability to access a set of public and/or private core networks. The wireless terminal device may be configured to automatically or manually search and select a core network to carry its data traffic. Each core network, a private core network in particular, may optionally be further associated with a human readable network name in addition to its unique network ID. A wireless access network node of a radio access network may disseminate the network IDs and the optional human readable network names of the core networks sharing the wireless access network node to wireless terminal devices. The human readable network names may be used by wireless mobile terminals to facilitate manual selection of servicing core networks.
This disclosure relates to mobile core network information dissemination by a wireless access network node to wireless terminal devices to assist the wireless terminal devices to perform manual core network selection. In particular, a multi-stage process is disclosed for dissemination of human readable network names for core networks supported by a wireless access network node. A human readable name presence indicator may be disseminated with network IDs of the supported core networks. Actual human readable names may be separately disseminated by the wireless access network node either spontaneously or on demand in response to requests from the wireless terminal devices.
In one implementation, a method performed in a wireless access network node is disclosed. The method may include generating a core-network availability system information message comprising: a first network identifier corresponding to a first core network that connects to the wireless access network node; and a first network name presence indicator data field corresponding to the first core network. The method may further include broadcasting the core-network availability system information message to wireless user terminal devices via a first predefined over-the-air (OTA) signaling interface, wherein the first network name presence indicator data field notifies the wireless user terminal devices whether a first human readable network name (HRNN) corresponding to the first core network is obtainable from a separate system information message transmitted by the wireless access network node.
In another implementation, a method performed by a wireless terminal device is disclosed. The method may include searching for service availability of a predetermined list of private core networks to identify a subset of available private core networks among the predetermined list of private core networks; identifying a wireless access network node that is available to provide network connection to one or more of the subset of available private core networks; receiving a core-network availability system information message broadcasted from the wireless access network node. The core-network availability system information message comprises a set of network identifiers corresponding to the one or more of the subset of available private core networks; and a set of network name presence indicator data fields. The method may further include determining, based on the set of network name presence indicator data fields and the set of network identifiers, which of the one or more of the subset of available private core networks are associated with human readable network names (HRNNs) obtainable from an HRNN system information message transmitted by the wireless access network node separately from the core-network availability system information message.
In another implementation, a method performed by wireless terminal device is disclosed. The method may include searching for service availability of a predetermined list of private core networks to determine a subset of available private core networks among the predetermined list of private core networks; selecting a wireless access network node available to provide network connection to of the subset of available private core networks; receiving a core-network availability system information message broadcasted from the wireless access network node. The core-network availability system information message may include a network identifier corresponding to the one of the subset of available private core networks; and one of a voice/IMS emergency support indicator data field corresponding to the one of the subset of available private core networks and indicating whether a voice or IMS emergency service is supported by the one of the subset of available private core networks; an eCall-over-IMS support indicator data field corresponding to the one of the subset of available private core networks and indicating whether an eCall-over-IMS service is supported by the one of the subset of available private core networks; or a network slicing support indicator data field corresponding to the one of the subset of available private core networks and indicating whether a network slicing service is supported by the one of the subset of available private core networks. The method may further include determining, based on the network identifiers, and one of the voice/IMS emergency support indicator data field, the eCall-over-IMS support indicator data field, or the network slicing support indicator data field, whether the one of the subset of available private core networks support the voice or IMS emergency service, the eCall-over-IMS service, or the network slicing service; and extracting the voice/IMS emergency support indicator data field, the eCall-over-IMS support indicator data field, or the network slicing support indicator data field from the core-network availability system information message and forwarding to an upper layer in the wireless terminal device for further processing.
In some other implementations, a communication device is disclosed. The communication device main include one or more processors and one or more memories, wherein the one or more processors are configured to read computer code from the one or more memories to implement any one of the methods above.
In yet some other implementations, a computer program product is disclosed. The computer program product may include a non-transitory computer-readable program medium with computer code stored thereupon, the computer code, when executed by one or more processors, causing the one or more processors to implement any one of the methods above.
The above embodiments and other aspects and alternatives of their implementations are explained in greater detail in the drawings, the descriptions, and the claims below.
As shown in
The OTA interfaces between the RANs 102 and the UEs 150 may be implemented using various wireless access technologies to cover a certain geographic region. For example, the RANs 102 may rely on cellular technologies to reuse radio resources. As such, the RANs may be implemented as various cells that collectively covers a service geographic region. Each cell may include one or more wireless access network nodes (WANN). Each of the UEs 150 may be registered, configured, and authenticated to access one or more of the WANNs.
The carrier network 101 may be provided by one or more service providers or network carriers. For example, a network carrier may provide both the RANs 102 and the core network 103 for an integrated wireless network access by the UEs 150. For another example, there may be multiple core networks, such as the core networks 110, 120, and 130 shown in
The core networks 103 may include both public and non-public core networks. For example,
Each of the public core networks 110 and private core networks 105 may be assigned and associated with a network identity. For example, each of the core networks 103, either public or private, may be associated with an overall network identification, referred to herein as a PLMN ID. In some implementations, public core networks 110 may be uniquely identified by their PLMN IDs whereas multiple private core networks may share a same PLMN ID. In other words, multiple private core networks 120 and 130 may be provided under a same PLMN ID. For example, a private core network provider may offer multiple independent SNPNs under a same PLMN ID. For another example, a private core network provider may lease network resources from a PLMN to provide services to multiple CAGs and these multiple different CAGs core networks may naturally assume the same PLMN ID as the underlying PLMN core network. These private core networks associated with the same PLMN IDs may be further identified by private network IDs attached or appended to their PLMN IDs. A private core network ID may be specified as either an SNPN ID or a CAG ID, depending on the nature of the private core network being either an SNPN or a CAG core network. In some implementations, private network IDs of the SNPN core networks may be reusable in different geographic areas since the SNPN core networks tend to be local, whereas private network IDs of the CAG core networks may be unique within large geographic regions due to their more global nature compared to the SNPN core networks. As such, the PLMN ID and private network ID combinations for the SNPN core networks may not be globally unique whereas the PLMN ID and private network ID combinations for the CAG core networks may tend to be globally unique.
In the example of
The core networks 103 may be associated and configured with human readable network names (HRNNs). HRNNs may be particularly helpful for a user of a UE to recognize a private core network during manual selection of a servicing core network in the UE. HRNNs may be optional for the core networks 103. In other words, some core networks 103 may not be associated with any HRNNs. In some example implementations, none of the PLMN core networks 112-118 may be associated with any HRNN, as shown by the empty “( )” in 112-118. Further in the example of
A WANN of a wireless cell may advertise or notify its supported list of core networks to UEs 150 within the service area of the wireless cell. As shown by 140 of
In such a manner, the core network information dissemination from the WANN may be implemented in stages and as needed. In particular, a UE 150 may read and process the broadcast message 202 in a first stage and proceed into a second stage to further obtain one or more HRNNs only if they are needed by the UE and the corresponding HRNN indicator data fields signify that these HRNNs do exist. When an HRNN presence indicator data field signifies to the UE that no optional HRNN is present for the corresponding core network, the UE would not need to proceed further in an attempt to obtain non-existent information, thereby reducing the amount of data transmission and power consumption in the UE.
Continuing with
The messages 202 and 206, and the HRNN request 204 may be implemented via System Information Blocks (SIBs) or other signaling interfaces. Each of these messages may be transmitted using separate and independent SIBs or other signaling interfaces. In some exemplary implementations in 5G wireless networks, the messages 202 and 204 may be transmitted via the SIB1 and SIB10 interfaces, respectively. They may be alternatively transmitted via non-access stratum signaling interfaces or dedicated radio resource control (RRC) signaling interfaces. The HRNN request message 204, for another example, may be transmitted via a random channel access preamble interface, an RRC interface, or an uplink dedicated control channel (UL DCCH). Other signaling channels/interfaces or SIBs may be used for transmitting messages 202, 204, and 206.
The core network ID broadcast message 202, for example, may be included in the SIB1 and configured to specify the lists of core networks supported by the WANN and other system information. The core network lists and the other system information may be specified in the manner illustrated by the example SIB1 message configuration scheme shown below (labeled as Configuration 1):
The SIB1 message configuration scheme above illustrates how the lists of SNPN core networks and CAG core networks may be specified in the message 202. For simplicity, the core network list above does not include lists of PLMN core networks which typically are not associated with any HRNNs. The example configuration scheme above thus specifies one or more lists (the sequence of “SNPN-Identity Info” above) of SNPN core networks with each list having a common PLMN ID. Each list of SNPN core networks having a common PLMN ID is specified by the sequence of “snpn-IDInfoList”. In an SNPN list, the SNPN IDs of the SNPN core networks are specified. In addition, HRNN presence indicators for the SNPN core networks in the SNPN list (“redableNamePresent” data field in the sequence of “SNPNInfo”, as highlighted in bold font above) are included to indicate whether the HRNNs corresponding to the SNPN IDs are present and can be obtained in a separate system information message 206 from the WANN.
Likewise, the example SIB1 message configuration scheme above also specifies one or more lists (the sequence of “CAG-Identity Info” above) of CAG core networks with each list having a common PLMN ID. Each list of CAG core networks having a common PLMN ID is specified by the sequence of “cag-IDInfoList” above. In a CAG list, the CAG-IDs of the CAG core networks are specified. In addition, HRNN presence indicators for the CAG core networks in the CAG list (“redableNamePresent” data field in the sequence of “CAGInfo” above) are included to indicate whether the HRNNs corresponding to the CAG-IDs are present and can be obtained in a separate system information message 206 from the WANN.
Other highlighted data fields (the bold-font data fields other than the “readableNamePresent” data field) in the example SIB1 Configuration 1 above further specify several other optional service capabilities of the SNPN and CAG core networks listed in the message 202 of
The implementation shown in the example SIB1 message configuration scheme above (Configuration 1) specifies the availability of the voice/IMS emergency service and the eCallOverIMS service for each SNPN or CAG core network individually. In some other implementations, one voice/IMS emergency availability data field and/or one eCallOverIMS availability data field may be specified for all SNPN core networks. Likewise, one voice/IMS emergency availability data field and/or one eCallOverIMS availability data field may be specified for all CAG core networks. Portions of an example SIB1 message configuration specifying availability of these services are shown below (labeled as “Configuration 2” and “Configuration 3”):
Based on the Configuration 2 and Configuration 3, if the UE operates in the SNPN mode, the UE shall ignore the “cellreservedforotheruse” data field shown in Configuration 1 and decide whether the network support Voice/IMS-Emergency or eCallOverIMS based on the IMS-EmergencySupport-SNPN or the eCallOverIMS-Support-SNPN data fields above.
If the UE does not operate in the SNPN mode and is instead configured with an allowed CAG list, the UE shall check “cellreservedforotheruse” data field shown in Configuration 1 first to decide whether this cell is reserved for SNPN. If the cell is reserved for SNPN, the UE may not further check the IMS-EmergencySupport-CAG or the eCallOverIMS-Support-CAG to decide whether the network support IMS-Emergency/eCallOverIMS through the CAG cell.
The Configuration 1 above further include other system information related to the WANN, such as the whether the cell is reserved for various uses (including uses for SNPN, data field “cellReservedForOtherUse”) and other cell information, which are self-explanatory in the Configuration 1.
The core networks in the SNPN lists and CAG lists shown in the SIB1 message scheme of Configuration 1 above and the PLMN core network lists (not shown above for simplicity) may be ordered and indexed according to some predefined ordering and indexing rules. These ordering and indexing rules may be specified by a protocol. Table 1 below shows an example core network index allocation (0 to 11) for the 12 core networks connected to and sharing the WANN in
Turning to the message 206 of
A further illustrative example following Configuration 4 with specific set of HRNNs and network indexes is shown below in Configuration 5. As shown in Configuration 5, HRNNs of core networks with network indexes of “4” and “8” (out of indexes 0-11, for example, and as illustrate in bold-font in Configuration 5) are specified. The network IDs for these core networks are determined by these network indexes according to, for example, the association between the network indexes and the network IDs in Table 1.
Alternatively, the message 206 may specify association of the listed HRNNs with SNPN and CAG core networks with positional information of the HRNN list embedded in the message 206. An example of such an implementation is shown in an SIB10 message configuration scheme below (labeled as “Configuration 6”). Specifically, the highlighted “redableName” sequence below is a sequence of components each corresponding to one of the network indexes in, for example, Table 1. For the core networks that do not have any HRNN, the corresponding components in the “redableName” sequence would be specified as being empty. Otherwise, a HRNN would be listed.
A further example following Configuration 6 with a specific set of HRNNs is illustrated below in Configuration 7. As shown in Configuration 7, specific HRNNs of core networks with network index of “4” and “8” (out of indexes 0-11, for example, and as illustrate in bold-font) are specified. Core networks with indexes 0-3, 5-7, and 9-11 are not associated with any HRNNS and these corresponding components in the “ReadableName” sequence do not specify any HRNNs. Again, the network IDs for the core networks listed in the Configuration 7 are determined by their positions in the sequence as indexes into Table 1.
In some implementations, the message 206 of
The ordering of the individual bits in the bit map above may be implemented in various exemplary manners. In some implementations, the bit map “presenceOfHRNN” may be ordered in correspondence to the SNPN and CAG core network lists. For the core networks in Table 1, for example, there are four SNPN core networks and four CAG core networks, and as such, the first four bits of the bit map “presenceOfHRNN” may be used to indicate presence of HRNNs for the four SNPN core networks in the “humanReadableName” sequence above (e.g., with “1” indicating an association, and “0” indicating no association). The next four bits in the bit map “pressenceOfHRNN” may be used to indicate presence of HRNNs for the four CAG core networks in the “humanReadableName” sequence. The bit map “presenceOfHRNN” may be set at a length determined by the maximum number of core networks that may be supported by the WANN (e.g., 12). The rest of the 12 bits may be used to indicate presence of HRNNs for PLMN core networks in the “humanReadableName” sequence (if some PLMN core networks are associated with HRNNs). Unused bits in the bit map may be zero padded. For the example of Table 1, a bit map “presenceOfHRNN” of “110000110000” would indicate that the first and second SNPN core networks (indexes 4 and 5 in Table 1) out of the four SNPN core networks, and the third and fourth CAG core networks (indexes 10 and 11 in Table 1) out of the four CAG core networks are associated with HRNNs. Correspondingly, four HRNNS may be listed in the “humanReadableName” sequence above and corresponding to core networks with indexes in the order of index 4, 5, 10, and 11 in Table 1.
In some alternative implementations to the Configuration 8 above, multiple bit maps rather than a single bit map may be included in the SIB10 message for indicating association between core networks and HRNNs. The HRNNs may be specified in either a single sequence or in multiple sequence corresponding to the multiple bit maps. An example of such an implementation is shown in an SIB10 message configuration scheme below (labeled as “Configuration 9”). In Configuration 9, separate HRNN presence bit maps are specified for the SNPN core networks and CAG core networks, as highlighted below. A single sequence of HRNNs are specified in the example of Configuration 9.
The ordering of the individual bits in the multiple bit maps in the Configuration 9 above may be implemented in various exemplary manners. In some implementations, the bit maps “presenceOfHRNN” for the SNPN core networks and the CAG core networks may be ordered in correspondence to the SNPN and CAG core network lists, respectively. The bit maps may each be set at a bit-length determined by the maximum number of core networks that may be supported by the WANN (e.g., 12). For the core networks in Table 1, for example, there are four SNPN core networks and four CAG core networks. The first four bits of the “presenceOfHRNN” bit map for the SNPN core networks may be used to indicate whether the four SNPN core networks are associated with any HRNNs (e.g., with “1” indicating an association, and “0” indicating no association). The rest of the 8 bits in this bit map may be zero padded. Likewise, the first four bits of the bit map “presenceOfHRNN” for the CAG core networks may be used to indicate presence of HRNNs for the four SNPN core networks and the rest of the 8 bits in this bit map may be zero padded. For the example of Table 1, a bit map “presenceOfHRNN” of “101000000000” for the SNPN core networks would indicate that the first and third SNPN core networks (indexes 4 and 6 in Table 1) are associated with HRNNs. Likewise, a bit map “presenceOfHRNN” of “011100000000” for the CAG core networks would indicate that the second, third, and fourth CAG core networks (indexes 9, 10, and 11 in Table 1) are associated with HRNNs. Correspondingly, five HRNNS may be listed in the single “humanReadableName” sequence of the Configuration 9 above and corresponding to core networks indexes in the order of index 4, 6, 9, 10, and 11 in Table 1.
While the message 206 containing the list or lists of HRNNs with or without the bit maps in the example configurations above are illustrated as being sent via SIB10 interface, it may be alternatively transmitted using other signaling interfaces including but not limited to other SIBs, non-access stratum (NAS) signaling interface, or radio resource control (RRC) signaling interface, other broadcasting/unicasting signaling interfaces, and signal interfaces for providing on demand system information.
The list of HRNNs may be acquired by a UE either following spontaneous broadcasting of the message 206 by the WANN or by triggered broadcasting/unicasting of message 206 as prompted by an HRNN request message 204 from the UE, as discussed above in connection with
For example, in the HRNN request message 204, the UE may send a requesting bit map for indicating the core networks for which HRNNs are requested. The requesting bit map may be formulated in a similar manner as the HRNN presence bit maps described above in relation to Configurations 8 and 9, except that the bits within the requesting bit map are used to indicate whether HRNNs are inquired by the UE for the corresponding core networks. Upon receiving the request, the WANN may extract the requesting bit map and determining the set of one or more core networks for which HRNNs are requested, and then retrieve the HRNN information to compose the message 206 with requested HRNN information. The message 206 in this case may be transmitted as SIB10 message following the SIB10 configurations discussed above or may be transmitted using other alternative configurations and signaling interfaces.
The HRNN request message 204 may be transmitted via an SIB interface, a random channel access preamble interface, an RRC interface, an uplink dedicated control channel (UL DCCH), or other system information signaling interface. An example configuration of the HRNN request message 204 as a RRC system information request message is shown below (labeled as Configuration 10). In the example of Configuration 10, the HRNN request bit map is used to identify the core networks for which the HRNNs are requested.
HRNN requests 204 may be sent by multiple UEs to the WANN and each UE may request HRNNs for a different sets of one or more core networks. In some implementations, the WANN may broadcast a message 206 each time a request 204 is made, but may compose the HRNN lists in the messages 206 in an accumulative manner, as illustrated in the example messaging flow below:
(1) Step 1: UE 1 sends a first request message with a first Requested-HRNN-bitmap which only indicates core network with, e.g., index 4 in Table 1.
(2) Step 2: The WANN sends a first SIB10 message providing an HRNN only for core network with index 4 according to Table 1:
(3) Step 3: UE 2 sends a second request message with a second Requested-HRNN-bitmap which only indicate core network with, e.g., index 8 in Table 1.
(4) Step 4: The WANN sends a second SIB10 message with the HRNNs of core networks correspond to both index 4 and index 8:
Moving on to operations in the UE side for obtaining HRNN information,
Table 2 below further summarizes and includes additional information with respect to the functionality of the NAS and AS layers of the UE 150 in the manual selection of SNPN/CAG core network selection.
The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.
Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment/implementation” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment/implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.
In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and”, “or”, or “and/or,” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a,” “an,” or “the,” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.
Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.
Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/CN2019/109533 | Sep 2019 | US |
| Child | 17682947 | US |
