Methods and apparatus for network access management in mobile communications

Abstract

Various solutions for network access management with respect to an apparatus in mobile communications are described. The apparatus may obtain at least one security context associated with at least one Mobile Network Operator (MNO). The at least one security context may include a first security context associated with a first MNO. The apparatus may apply a security operation to an initial message based on the first security context. The apparatus may transmit the initial message applied with the security operation to the first MNO for establishing a connection.

Description

METHODS AND APPARATUS FOR NETWORK ACCESS MANAGEMENT IN MOBILE COMMUNICATIONSCROSS REFERENCE TO RELATED PATENT APPLICATION (S)

[0001] The present disclosure is part of a non-provisional application claiming the priority benefit of U.S. Patent Application No. 63 / 736,700, filed 20 December 2024, and of U.S. Patent Application No. 63 / 737,840, filed 23 December 2024, the contents of which herein being incorporated by reference in their entirety.TECHNICAL FIELD

[0002] The present disclosure is generally related to mobile communications and, more particularly, to network access management with respect to apparatus in mobile communications.BACKGROUND

[0003] Unless otherwise indicated herein, approaches described in this section are not prior art to the claims listed below and are not admitted as prior art by inclusion in this section.

[0004] While the fifth-generation (5G) mobile communication architecture mitigates several security weaknesses of legacy systems, it introduces new challenges related to latency, performance, and certain attack vectors. In particular, the establishment of an initial security context requires the execution of a full authentication procedure involving signaling exchanges among a device, a serving network, and a home network, resulting in increased access latency, which is further exacerbated in roaming scenarios due to inter-network round-trip delays. Additionally, a vulnerability window exists prior to authentication completion, enabling downgrade attacks through registration rejection. Moreover, repeated authentication failures may exploit sequence number synchronization mechanisms, causing denial-of-service conditions.

[0005] Furthermore, in current mobile communication systems, network selection and quality control are predominantly driven by static, operator-managed policies. Such policy-based behavior limits the ability to reflect user intent at session time, for example, prioritizing uninterrupted voice service during mobility at the expense of other services. Moreover, over-the-top (OTT) service providers are unable to reliably secure per-user, over-the-air quality of service or quality of experience guarantees, even when users subscribe to premium services. Although mechanisms such as network slicing, traffic steering, and per-flow quality of service (QoS) exist in 5G systems, their deployment is fragmented and constrained, particularly under roaming scenarios, thereby preventing consistent intent-driven service delivery.

[0006] In addition, in existing mobile communication systems, an application executed on a User Equipment (UE) is typically bound to a single mobile network operator (MNO) according to the user’s subscription. Consequently, the application relies solely on the connectivity of that MNO, without access to alternative transmission paths across other available networks. Such a limitation prevents the application from achieving service resiliency, maintaining service availability, or ensuring consistent quality of service or user experience when the subscribed MNO exhibits congestion, coverage degradation, or network instability. As a result, application performance remains constrained by the capabilities of a single operator’s network.

[0007] Additionally, a UE may already maintain a full service context with a serving network. However, when the UE seeks to extend coverage via a Non-Terrestrial Network (NTN) or a similar access network, establishing or updating the service context may become inefficient. In particular, narrowband satellite links and long propagation distances introduce substantial signaling latency, may require re-registration procedures, consume limited shared-band resources, and increase power consumption at the UE. Moreover, satellite systems typically operate as forwarding entities for control signaling and do not host core network functions, which may result in duplicated signaling transmissions and further degrade overall signaling efficiency.SUMMARY

[0008] The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce concepts, highlights, benefits and advantages of the novel and non-obvious techniques described herein. Select implementations are further described below in the detailed description. Thus, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

[0009] An objective of the present disclosure is to propose solutions or schemes that address the aforementioned issues pertaining to network access management with respect to apparatus in mobile communications.

[0010] In one aspect, a method may involve an apparatus obtaining at least one security context associated with at least one Mobile Network Operator (MNO) . The at least one security context may include a first security context associated with a first MNO. The method may further involve the apparatus applying a security operation to an initial message based on the first security context. The method may further involve the apparatus transmitting the initial message applied with the security operation to the first MNO for establishing a connection.

[0011] In one aspect, a method may involve an apparatus determining a Quality of Experiences (QoE) item for a User Equipment (UE) . The method may further involve the apparatus determining a Quality of Service (QoS) item associated with the QoE item based on a Service Level Agreement (SLA) . The method may further involve the apparatus transmitting the QoS item to an operator for adjusting a communication between the UE and the operator.

[0012] In one aspect, a method may involve an apparatus determining a service requirement associated with a UE. The method may further involve the apparatus determining an operator from a plurality of operators based on the service requirement. The method may further involve the apparatus instructing the UE to switch to the operator from another operator.

[0013] In one aspect, a method may involve an apparatus initiating a service via a Non-Terrestrial Network (NTN) . The method may further involve the apparatus determining a container identification associated with the service. The method may further involve the apparatus transmitting the container identification to an operator via the NTN for determining a container associated with the container identification. The method may further involve the apparatus utilizing the service based on the container.

[0014] In one aspect, an apparatus may comprise a transceiver which, during operation, wirelessly communicates with a wireless network. The apparatus may also comprise a processor communicatively coupled to the transceiver. The processor, during operation, may perform operations described above.

[0015] It is noteworthy that, although description provided herein may be in the context of certain radio access technologies, networks and network topologies such as Long-Term Evolution (LTE) , LTE-Advanced, LTE-Advanced Pro, 5th Generation (5G) , New Radio (NR) , Internet-of-Things (IoT) and Narrow Band Internet of Things (NB-IoT) , Industrial Internet of Things (IioT) , and 6th Generation (6G) , the proposed concepts, schemes and any variation (s)  / derivative (s) thereof may be implemented in, for and by other types of radio access technologies, networks and network topologies. Thus, the scope of the present disclosure is not limited to the examples described herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of the present disclosure. The drawings illustrate implementations of the disclosure and, together with the description, serve to explain the principles of the disclosure. It is appreciable that the drawings are not necessarily in scale as some components may be shown to be out of proportion than the size in actual implementation in order to clearly illustrate the concept of the present disclosure.

[0017] FIG. 1 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0018] FIG. 2 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0019] FIG. 3 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0020] FIG. 4 is a diagram depicting an example scenario under schemes in accordance with implementations of the present disclosure.

[0021] FIG. 5 is a block diagram of an example communication system in accordance with an implementation of the present disclosure.

[0022] FIG. 6 is a flowchart of an example process in accordance with an implementation of the present disclosure.

[0023] FIG. 7 is a flowchart of an example process in accordance with an implementation of the present disclosure.

[0024] FIG. 8 is a flowchart of an example process in accordance with an implementation of the present disclosure.

[0025] FIG. 9 is a flowchart of an example process in accordance with an implementation of the present disclosure.

[0026] FIG. 10 is a flowchart of an example process in accordance with an implementation of the present disclosure.

[0027] FIG. 11 is a flowchart of an example process in accordance with an implementation of the present disclosure.

[0028] FIG. 12 is a flowchart of an example process in accordance with an implementation of the present disclosure.

[0029] FIG. 13 is a flowchart of an example process in accordance with an implementation of the present disclosure.

[0030] FIG. 14 is a flowchart of an example process in accordance with an implementation of the present disclosure.

[0031] FIG. 15 is a flowchart of an example process in accordance with an implementation of the present disclosure. DETAILED DESCRIPTION OF PREFERRED IMPLEMENTATIONS

[0032] Detailed embodiments and implementations of the claimed subject matters are disclosed herein. However, it shall be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matters which may be embodied in various forms. The present disclosure may, however, be embodied in many different forms and should not be construed as limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided so that description of the present disclosure is thorough and complete and will fully convey the scope of the present disclosure to those skilled in the art. In the description below, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations. Overview

[0033] Implementations in accordance with the present disclosure relate to various techniques, methods, schemes and / or solutions pertaining to network access management with respect to apparatus in mobile communications. According to the present disclosure, a number of possible solutions may be implemented separately or jointly. That is, although these possible solutions may be described below separately, two or more of these possible solutions may be implemented in one combination or another.

[0034] FIG. 1 illustrates an example scenario 100 under schemes in accordance with implementations of the present disclosure. In some embodiments, a network system may include a User Equipment (UE) , a home network device and at least one Mobile Network Operator (MNO) . The at least one MNO may include a first MNO.

[0035] In some implementations, the home network device may determine at least one security context associated with the at least one MNO. The at least one security context may include a first security context associated with the first MNO. The home network device may configure (e.g., pre-configure) the UE the at least one security context. In other words, the UE may obtain the at least one security context from the home network device in advance. In some cases, each security context may include: (1) a security algorithm, (2) a key material, and / or (3) a context identification.

[0036] In some implementations, when the UE needs to initiate connection with the first MNO, the UE may apply a security operation to an initial message based on the first security context. The UE may transmit the initial message applied with the security operation to the first MNO for establishing a connection.

[0037] In some cases, the security operation may include at least one of a ciphering and an integrity. In some cases, the initial message may include: (1) a Non-Access Stratum (NAS) message for network registration or service request, or (2) a Random Access Channel (RACH) message for initiating access to a radio access network.

[0038] In some implementations, the first MNO may receive the initial message from the UE. The first MNO may obtain the security context to verify the initial message. After verifying the initial message, the first MNO may establish the connection with the UE based on the initial message.

[0039] Accordingly, the above-described network architecture of the present disclosure may enable efficient and secure connection establishment by allowing security operations to be applied to an initial message using a pre-configured security context. By pre-provisioning security context information to the UE in advance, the need to perform a full authentication procedure during initial access may be reduced or avoided, thereby lowering signaling overhead and reducing initial access latency. For example, this approach is beneficial in roaming and multi-operator scenarios, where conventional authentication procedures incur additional delay. Moreover, enabling ciphering and integrity protection at an early stage of the access procedure may limit exposure to pre-authentication vulnerabilities, such as downgrade attacks and Denial-of-Service (DoS) conditions, and improve overall robustness of the network system.

[0040] More specifically, the present disclosure may enable activation of access network security for control and signaling procedures starting from the initial message transmitted by the UE, instead of waiting until the network system completes conventional security activation procedures.

[0041] Protection may begin with an initial NAS message, for example, when the UE is configured for direct communication over a non-trusted network using IP-based connectivity, virtual private networks (VPNs) , or other tunneling mechanisms.

[0042] This functionality may be achieved by the home network device provisioning the UE in advance with network identity information (e.g., a temporary identity) and a corresponding security context of a corresponding MNO associated with a context identifier. The provisioned security context may enable the UE to perform ciphering and integrity protection according to configured security algorithms starting from the initial access message.

[0043] It should be noted that when a currently connected network (e.g., the first MNO) does not locally possess a security context of the UE, the connected network may use information contained in the initial message (e.g., a UE identity, a security context identifier, and optionally additional routing information such as an IP address) to retrieve the corresponding security context from an authoritative source (e.g., the home network device or a trusted local database) . In contrast to conventional solutions that require execution of identity procedures, authentication, and Security Mode Command (SMC) signaling, the network architecture of the present disclosure may avoid time-consuming in situ security establishment and may not require persistent security context storage at the connected network.

[0044] After retrieving the security context, the connected network may derive a local security context for the authenticated UE and synchronize the derived context with the UE. In some cases, a Subscriber Identity Module (SIM) , an embedded-SIM (eSIM) , or equivalent secure element may be required to support storage of multiple root key values (e.g., Key for Access and Mobility Management Function (KAMF) , etc. ) , with each root key corresponding to a different provisioned MNO. Supporting multiple independent security contexts may further allow the security context to evolve over time.

[0045] In operation, the UE may protect an initial message, such as an initial NAS message or an initial RACH message, using a stored security context when such a context exists. Upon receiving the protected initial message, the connected network may retrieve the corresponding security context from a database and use the retrieved security context to decipher the message and perform integrity verification. Using the verified information, the connected network may derive user identity information and authenticate the UE based on security material included in the initial message and information pre-negotiated with the home network device.

[0046] From a provisioning perspective, the UE may enter into a subscription agreement with the home network device that provides a SIM or eSIM to the UE. The SIM or eSIM may include an initial security context and, optionally, additional security contexts for known collaborating MNOs to enable fast roaming. During an initial access, the subscribed home network device may provision a root of trust within the UE (e.g., a SIM, an eSIM, Universal-SIM (USIM) , virtual SIM, secure enclave, or similar secure storage) with one or more security contexts.

[0047] In some scenarios, multiple home network devices (e.g., in a dual-SIM device) may independently provision security contexts for the same target network. For example, each of two different home network devices provisions a security context corresponding to a shared non-terrestrial network (NTN) . Additionally, a home network device provisions security contexts for different access technologies or systems, including 4G, 5G, Wi-Fi, and NTN, or for other MNOs to extend coverage in a manner similar to roaming.

[0048] To enable correct security context selection, the UE may be configured to identify a discovered network and select a corresponding security context from the root of trust. Therefore, some broadcast information (e.g., System Information Block (SIB) message or Master Information Block (MIB) message in existing systems) may provide network identity information used by the UE for context selection. In some cases, alternative protected mechanisms may be used to announce network identity, particularly in virtualized or indirect access scenarios. In some cases, broadcast messages (e.g., MIB message or SIB message) may themselves be integrity-protected or ciphered using public key mechanisms provisioned by the SIM or acquired during registration.

[0049] When the security context is available, the security context may be activated immediately, thereby avoiding additional latency. This procedure may enable the UE to establish a secure signaling connection with a provisioned network without relying on unverified or unauthenticated network responses. As a result, exposure to DoS attacks and other attack vectors associated with unprotected initial message exchange may be reduced.

[0050] By using a USIM or similar secure storage as a root of trust and pre-provisioning security contexts that enable authentication, identity protection, and signaling protection from the initial access message, the above-described network architecture of the present disclosure may provide secure connectivity to known networks with switching-like performance. The UE may avoid establishing a security context during initial access and instead reuse an existing security context stored in a root of trust, thereby reducing latency and improving security.

[0051] FIG. 2 illustrates an example scenario 200 under schemes in accordance with implementations of the present disclosure. In some embodiments, a network system may include a UE, a service provider device and an MNO.

[0052] In some implementations, the UE may communicate with the service provider device. The UE may provide user requirements to the service provider device. Based on the user requirement, the service provider device may determine a Quality of Experiences (QoE) item for the UE. The service provider device may determine a Quality of Service (QoS) item associated with the QoE item based on a Service Level Agreement (SLA) . The service provider device may transmit the QoS item to the MNO for the UE to adjust a communication between the UE and the MNO based on the QoS item.

[0053] In some cases, the user requirement may include at least one of a user-intent based request and a user subscription. The QoE item may be associated with the user-intent based request and / or the user subscription. For example, the user-intent-based request is an Extended Reality (XR) service request. In another example, the subscription indicates that the UE subscribes to a service for high-quality streaming video. In some cases, the QoS item may be associated with at least one of a QoS flow, a mobility policy, a traffic scheduling, and a QoS packet forwarding.

[0054] In some cases, the SLA may be associated with a plurality of mappings between QoE and QoS. The service provider device may determine the QoS item associated with the QoE item based on the mappings associated with the SLA.

[0055] In some cases, the SLA may be predetermined between the service provider device and the MNO. In particular, the SLA may be agreed in advance for services provided by the service provider and may define mappings between QoE of the services and QoS to be implemented by the MNO when at least one of the services is activated by the UE.

[0056] In some cases, the QoE-to-QoS mappings may be defined not only by a service-specific SLA, but alternatively or additionally by one or more standardized QoE profiles that define predefined QoE classes and corresponding QoS characteristics.

[0057] More specifically, current network architectures may not allow dynamic control over service delivery to realize innovative services, or alternatively, result in complex and impractical schemes. In particular, existing mobile networks may rely on static, operator-managed policies that may not accommodate user intent expressed at service activation time, nor do they enable service-provider-driven adaptation of quality of service or quality of experience on a per-user basis.

[0058] To address these limitations, a service provider-driven SLA model may be introduced, in which a UE subscription to the service provider device may be realized as an SLA in a currently serving MNO. The proposed model may enable service-and / or user-driven policy control in a manner that respects user-expressed intent.

[0059] In this model, the UE may subscribe to a specific service from the service provider device and pay for the specific service. The service provider device may compensate the MNO for implementing the SLA corresponding to the UE subscription. The UE may express intent through an application, thereby impacting policy control associated with the subscribed service.

[0060] Under the proposed model, the UE may select among SLA-related options, including but not limited to: (1) operator applications, such as voice or messaging applications, where service continuity (e.g., persistence of a voice call) may be dynamically controlled based on UE subscription options; and (2) OTT services, such as an XR haptic experience or gaming service, where quality requirements may be realized through a service provider SLA, which may be external to or coordinated with the MNO. The QoE expressed by the service provider device may reflect the UE subscription, thereby allowing the service provider device to act as a proxy for user intent toward the MNO.

[0061] The service provider device may communicate QoE requirements to the MNO using the SLA that may include QoE-to-QoS mappings and a set of policy-related options. The service provider device may charge the UE for the service, pay the MNO for implementing the SLA, and the MNO may realize the SLA within the network. In some cases, the service provider device may communicate QoE requirements to the MNO using an SLA and / or by referencing a standardized QoE profile, which may include predefined QoE-to-QoS mappings and policy-related options.

[0062] For example, streaming video service provider A, acting as a service provider device, offers an XR haptic video experience service. The service requires a latency lower than 20 milliseconds, a jitter of approximately 1 millisecond, and a minimum bit rate (MBR) of 1 Mbps. The service provider A defines QoE-to-QoS mappings for the service and creates a corresponding profile. The profile includes a set of QoS parameters, such as MBR, latency, reliability, and jitter, along with traffic flow template (TFT) information. The service provider A agrees on an SLA with an MNO to ensure that the defined QoE can be delivered to a UE. The SLA is predetermined or established using a digital contract or a similar process. The UE subscribes to the service from the service provider A and pays a premium for the service. The service provider A compensates the MNO for implementing the SLA associated with the UE subscription.

[0063] When the UE starts the service provider A application and activates the service, SLA-related traffic is identified and authorized by the network. Such identification is performed using an SLA-related traffic flow template, explicit authorization information provided by the service provider A, or a combination thereof. Upon authorization, the MNO implements QoS for packet forwarding according to the SLA and applies mobility and other related policies, such as excluding the service from a data cap, to ensure the SLA is met. While the service is active, the MNO schedules traffic and implements one or more QoS flows over the air interface, such as through a dedicated radio bearer or slice, and manages scheduling, service mobility, and other policies to realize the agreed SLA.

[0064] Existing implementations may depend on the maturity of standalone MNO deployments and the availability of exposure interfaces. In the near term, such implementations may rely on pilot deployments using exposure APIs, limited UE Route Selection Policy (URSP) steering, or targeted QoS elevation for specific services. Although future enhancements may be expected to broaden the adoption of these mechanisms, the proposed service provider-driven SLA model may offer a clearer and more practical framework for enabling user-intent-aware and per-user service delivery.

[0065] FIG. 3 illustrates an example scenario 300 under schemes in accordance with implementations of the present disclosure. In some embodiments, a network system may include a UE, a Service Area Network (SAN) controller, and a plurality of MNOs. It should be noted that, in FIG. 3, the SAN controller is illustrated as an independent component. However, it is not intended to be limiting. In some implementations, the SAN controller may include: (1) a controller owned by the UE; (2) a controller of a service provider device; (3) an independent SAN device controller; or (4) a controller associated with one of the MNOs.

[0066] In some implementations, from the perspective of the SAN controller, the SAN controller may determine a service requirement associated with the UE. The SAN controller configured with the MNOs may determine an MNO from the MNOs based on the service requirement. The SAN controller may instruct the UE to switch to the MNO from another MNO (e.g., from the original serving MNO) .

[0067] In some implementations, from the perspective of the UE, the UE may report service-related information to the SAN controller for generating the service requirement associated with the UE. The UE may receive an MNO switch instruction from the SAN controller. The operator switch instruction may be determined by the SAN controller based on the service requirement. The UE may switch from the original serving MNO to the MNO based on the operator switch instruction.

[0068] In some cases, the UE and the SAN controller may be capable of establishing a connection to each of the MNOs. In particular, the UE and the SAN controller may be configured with policies and network information that enable establishing communication with each of the MNOs to support access selection and MNO switching operations.

[0069] In some cases, the SAN controller may receive a request from a service provider device for determining the MNO. The request may be associated with the service requirement. In some cases, the SAN controller may receive a request to modify a control policy by setting conditions for determining the MNO. In other words, the UE may request the SAN controller for modifying the control policy by the setting conditions for determining the operator switch instruction.

[0070] More specifically, in existing network systems, an application executed on a UE may typically be bound to a single MNO according to a subscription. As a result, the application may rely on a single access network and may not have an alternative transmission path through other available networks operated by different MNOs. When the serving network experiences coverage loss, congestion, or quality degradation, the application may fall into a no-coverage state or a reduced service state, thereby failing to maintain required QoS or QoE.

[0071] The described network architecture of the present disclosure may address this problem by extending service availability across multiple MNOs through an SAN architecture. The SAN may form a logical network that connects to multiple access networks, each operated by a separate MNO, thereby enabling service continuity, resiliency, and uniform service quality during mobility.

[0072] In some implementations, the SAN may be realized in a standard-driven manner and operate in coordination with participating MNOs. Initially, a UE may register with one or more subscribed MNOs. The UE may have an association with a service provider providing an application A, a SAN controller, or otherwise acquires access to the SAN. The SAN may be configured for use by the application A.

[0073] When Application A is started on the UE, the application may establish a connection to the service provider of the application A using an existing network access. The application A may configure required policies for the SAN controller, or the SAN may already support a QoE or QoS profile required by the application A, such that the application only selects a profile.

[0074] The SAN controller may obtain information including the current location of the UE, available or seen networks, network states, and other information required to control access domain selection. When a currently selected MNO is determined to be unsuitable for use by the application A, the SAN controller may steer a network selection algorithm to select a more suitable MNO.

[0075] A control entity associated with the SAN controller may indicate network capability information to the application A, enabling the application to request the SAN controller to perform reselection based on application-side policies. For example, the application A observes degradation in QoS or receives feedback indicating insufficient QoE from the UE and requests the SAN controller to select a more suitable MNO by performing an MNO reselection procedure.

[0076] Additionally, the UE or the application A may request the SAN controller to modify control policies by setting conditions, such as limiting the selection of a particular MNO within a certain geographical area. The application A and the SAN controller may capture location-specific access network capability information for use by intelligent or algorithmic control.

[0077] In some implementations, the SAN may be realized by an external actor or may be user-driven, instead of being primarily implemented in a standard-driven manner. In these implementations, the SAN may be implemented by a Content Delivery Network (CDN) , a SAN service provider, an eSIM provider, or by a UE including a multi-SIM device. A SAN controller application may be deployed on the device to monitor subscribed network states and to perform policy-based control for MNO selection.

[0078] The SAN controller may monitor active applications, related policies, and available network capabilities, and perform MNO selection based on this information using policies that are user-specific or application-specific. In this manner, the SAN controller may enable dynamic selection among multiple MNOs without reliance on a single serving MNO.

[0079] The SAN may be operated by a UE-owned controller, a SAN operator that includes a group of MNOs, a SAN service provider, an application A provider, or a group of application providers.

[0080] The SAN may be formed by provisioned access credentials, policies, and configurations that are application-specific or service-specific, or that correspond to a generic application class, such as role-playing game (RPG) applications or XR assistance applications. Standardized profiles may be used to simplify SAN configuration and to inform participating MNOs of SAN configurations, thereby supporting interoperability. In some cases, standardized profiles may be used to simplify SAN configuration and to inform participating MNOs of SAN configurations, thereby supporting interoperability. In these cases, such standardized profiles may include standardized QoE profiles defining QoE classes and corresponding QoS characteristics applicable across multiple MNOs.

[0081] The SAN may be shared among multiple applications or service providers or may be dedicated to a particular application. A service provider may provide policies to an application or a device to perform MNO within the SAN. The SAN may also deliver capability information to applications to assist with the adjustment of application operations and the optimal use of the SAN.

[0082] The SAN may include separate control channels to facilitate policy-based control, announcement of SAN state, assignment of resources, authentication and authorization, and other common network functions. The SAN may be realized using standard network elements such as network slicing, or other similar constructs.

[0083] Traditional solutions may rely on a single MNO subscription model, where the UE connects to one serving MNO at a time. Mobility between MNOs may typically require roaming procedures or manual intervention, which may incur latency, service interruption, or degraded service quality. Applications may not be aware of alternative MNOs and may not influence MNO selection based on service requirements.

[0084] The described network architecture of the present disclosure may introduce a multi-MNO solution in which multiple MNOs may be combined into a continuous SAN. The SAN may enable low-latency mobility, service-driven access selection, and uniform service levels during mobility. By allowing coordinated control across multiple MNOs, the SAN may provide improved service availability, resiliency, and QoE compared to traditional single-MNO approaches.

[0085] FIG. 4 illustrates an example scenario 400 under schemes in accordance with implementations of the present disclosure. In some embodiments, a network system may include a UE, a Non-Terrestrial Network (NTN) , and an MNO.

[0086] In some implementations, the MNO may preconfigure the UE with a plurality of containers. Each container may include at least one of: (1) a container identification, (2) a QoS profile, (3) an access-type specific service policy, and (4) authorization data. The UE may store at least the container identifications of the corresponding containers. The UE may further store the containers. The UE and the MNO may determine a plurality of mappings between services and container identifications.

[0087] In some implementations, the authorization data may refer to a structured set of information that may enable controlled and secure access to network and service resources. The authorization data may encompass both logical access control information and security framework configuration information, as described below.

[0088] In some cases, logical access control may define who is allowed to access the system and what actions are permitted. This may include identity information, authentication material, and authorization data, ensuring that a user or device may be correctly identified, authenticated, and authorized to access the system.

[0089] In some cases, framework configuration may define how security is technically realized and enforced. This may include configuration parameters for Key Derivation Functions (KDFs) , encryption and integrity algorithms, and secure communication protocols (e.g., Transport Layer Security (TLS) ) , which may determine the cryptographic strength and operational behavior of the security framework.

[0090] In some implementations, the UE may initiate a specific service with the MNO via the NTN. Based on the mappings between services and container identifications, the UE may determine a specific container identification associated with the specific service. The UE may transmit the specific container identification to the MNO via the NTN. After receiving the specific container identification, the MNO may determine a specific container associated with the specific container identification. The MNO may provide the specific service to the UE based on the specific container. The UE may utilize the specific service based on the specific container.

[0091] In some cases, each QoS profile may include at least one of: (1) a bandwidth, (2) a latency, (3) a reliability, and (4) an availability. In some cases, the authorization data may include at least one of a user identity token and a service access token. In some cases, the specific service may be provided (by the MNO) or utilized (by the UE) based on the corresponding QoS profile of the specific container. In some cases, each QoS profile may further include a Traffic Flow Template (TFT) associated with the QoS profile, or information enabling the device or network to obtain (or derive) the corresponding TFT.

[0092] More specifically, the described network architecture of the present disclosure may introduce a signed service and access authorization container that may enable the establishment of a service without implicit or iterative signaling exchanges. The container may refer to one or more preconfigured service profiles and enable authentication of a UE and authorization of service access by the MNO.

[0093] In some implementations, each container may define access-type-specific service policies applicable to both the UE and the MNO. The service profiles may include QoS parameters such as bandwidth, latency, reliability, and availability of access. For example, for an NTN access, a profile specifies an allowed bandwidth of 100 kbps, a latency of 800 ms, a reliability of 80 percent, and an availability duration of ten seconds.

[0094] In some implementations, the UE may store one or more containers, each associated with a container identification. The container identification may act as a selector or pointer to corresponding service policies or contexts, thereby minimizing signaling by avoiding transmission of full service contexts over the air.

[0095] The service profiles referenced by the container may be defined in a specification and implemented in the UE for certain access types. Alternatively or additionally, the profiles may be provisioned by the MNO and cached in the UE, for example, within an eSIM. In some cases, the containers may be preconfigured by a home network device.

[0096] In some cases, a container identification may be defined per MNO, per MNO-service combination, or as a common container type associated with a particular service that may be usable across multiple MNOs.

[0097] In some implementations, the UE may use a stored container to activate or deactivate a service over a selected access, including an NTN access. In some cases, the UE may transmit a Registration Request message, in accordance with 3GPP standalone procedures, including a container information element carrying the corresponding container identification.

[0098] In some cases, the container may further carry authorization information, such as a user identity token or a service access token, for example, a service-specific identity associated with the UE and known by the MNO. Upon receiving the Registration Request, the MNO may confirm access and activation of the corresponding profile in a Registration Accept message. The UE may not require additional service-specific information beyond the container identification.

[0099] In some cases, the UE may transmit a Service Request message to the MNO, indicating the container identification as a service request type or subtype. The MNO may automatically establish the requested service based on the container, without further negotiation, and indicate resource allocation for the UE in an Accept message or decline the request in a Reject message. Illustrative Implementations

[0100] FIG. 5 illustrates an example communication system 500 having an example communication apparatus 510 and an example network apparatus 520 in accordance with an implementation of the present disclosure. Each of communication apparatus 510 and network apparatus 520 may perform various functions to implement schemes, techniques, processes and methods described herein pertaining to network access management with respect to UE and network apparatus in mobile communications, including scenarios / schemes described above as well as processes 600, 700, 800, 900, 1000, 1100, 1200, 1300, 1400, and 1500 described below.

[0101] Communication apparatus 510 may be a part of an electronic apparatus, which may be a UE such as a portable or mobile apparatus, a wearable apparatus, a wireless communication apparatus or a computing apparatus. For instance, communication apparatus 510 may be implemented in a smartphone, a smartwatch, a personal digital assistant, a digital camera, or a computing equipment such as a tablet computer, a laptop computer or a notebook computer. Communication apparatus 510 may also be a part of a machine type apparatus, which may be an IoT, NB-IoT, or IIoT apparatus such as an immobile or a stationary apparatus, a home apparatus, a wire communication apparatus or a computing apparatus. For instance, communication apparatus 510 may be implemented in a smart thermostat, a smart fridge, a smart door lock, a wireless speaker, a home control center, or a SAN apparatus having a SAN controller. Alternatively, communication apparatus 510 may be implemented in the form of one or more integrated-circuit (IC) chips such as, for example and without limitation, one or more single-core processors, one or more multi-core processors, one or more reduced-instruction set computing (RISC) processors, or one or more complex-instruction-set-computing (CISC) processors. Communication apparatus 510 may include at least some of those components shown in FIG. 5 such as a processor 512, for example. Communication apparatus 510 may further include one or more other components not pertinent to the proposed scheme of the present disclosure (e.g., internal power supply, display device and / or user interface device) , and, thus, such component (s) of communication apparatus 510 are neither shown in FIG. 5 nor described below in the interest of simplicity and brevity. In some cases, communication apparatus 510 may further include a secure component having an eSIM and / or a secure enclave for securely storing authorization and policy containers.

[0102] Network apparatus 520 may be a part of a network apparatus, which may be a network node such as a satellite, a base station, a small cell, a router or a gateway. For instance, network apparatus 520 may be implemented in an eNodeB in an LTE network, in a gNB in a 5G / NR, IoT, NB-IoT or IIoT network or in a satellite or base station in a 6G network. For instance, network apparatus 520 may be implemented in service provider device, an MNO, a SAN apparatus having a SAN controller. Alternatively, network apparatus 520 may be implemented in the form of one or more IC chips such as, for example and without limitation, one or more single-core processors, one or more multi-core processors, or one or more RISC or CISC processors. Network apparatus 520 may include at least some of those components shown in FIG. 5 such as a processor 522, for example. Network apparatus 520 may further include one or more other components not pertinent to the proposed scheme of the present disclosure (e.g., internal power supply, display device and / or user interface device) , and, thus, such component (s) of network apparatus 520 are neither shown in FIG. 5 nor described below in the interest of simplicity and brevity.

[0103] In one aspect, each of processor 512 and processor 522 may be implemented in the form of one or more single-core processors, one or more multi-core processors, or one or more CISC processors. That is, even though a singular term “a processor” is used herein to refer to processor 512 and processor 522, each of processor 512 and processor 522 may include multiple processors in some implementations and a single processor in other implementations in accordance with the present disclosure. In another aspect, each of processor 512 and processor 522 may be implemented in the form of hardware (and, optionally, firmware) with electronic components including, for example and without limitation, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors and / or one or more varactors that are configured and arranged to achieve specific purposes in accordance with the present disclosure. In other words, in at least some implementations, each of processor 512 and processor 522 is a special-purpose machine specifically designed, arranged and configured to perform specific tasks including network access management in a device (e.g., as represented by communication apparatus 510) and a network (e.g., as represented by network apparatus 520) in accordance with various implementations of the present disclosure.

[0104] In some implementations, communication apparatus 510 may also include a transceiver 516 coupled to processor 512 and capable of wirelessly transmitting and receiving data. In other words, processor 512 may transceive the data such as configuration, message, signal, information, indicator, etc. via transceiver 516. In some implementations, communication apparatus 510 may further include a memory 514 coupled to processor 512 and capable of being accessed by processor 512 and storing data therein. In some implementations, network apparatus 520 may also include a transceiver 526 coupled to processor 522 and capable of wirelessly transmitting and receiving data. In other words, processor 522 may transceive the data such as configuration, message, signal, information, indicator, etc. via transceiver 526. In some implementations, network apparatus 520 may further include a memory 524 coupled to processor 522 and capable of being accessed by processor 522 and storing data therein. Accordingly, communication apparatus 510 and network apparatus 520 may wirelessly communicate with each other via transceiver 516 and transceiver 526, respectively. To aid better understanding, the following description of the operations, functionalities and capabilities of each of communication apparatus 510 and network apparatus 520 is provided in the context of a mobile communication environment in which communication apparatus 510 is implemented in or as a communication apparatus or a UE and network apparatus 520 is implemented in or as a network node of a communication network.

[0105] In some implementations, each of memory 514 and memory 524 may include a type of random-access memory (RAM) such as dynamic RAM (DRAM) , static RAM (SRAM) , thyristor RAM (T-RAM) and / or zero-capacitor RAM (Z-RAM) . Alternatively, or additionally, each of memory 514 and memory 524 may include a type of read-only memory (ROM) such as mask ROM, programmable ROM (PROM) , erasable programmable ROM (EPROM) and / or electrically erasable programmable ROM (EEPROM) . Alternatively, or additionally, each of memory 514 and memory 524 may include a type of non-volatile random-access memory (NVRAM) such as flash memory, solid-state memory, ferroelectric RAM (FeRAM) , magnetoresistive RAM (MRAM) and / or phase-change memory. Illustrative Processes

[0106] FIG. 6 illustrates an example process 600 in accordance with an implementation of the present disclosure. Process 600 may be an example implementation of above scenarios / schemes, whether partially or completely, with respect to network access management of the present disclosure. Process 600 may represent an aspect of implementation of features of communication apparatus 510. Process 600 may include one or more operations, actions, or functions as illustrated by one or more of blocks 610 to 630. Although illustrated as discrete blocks, various blocks of process 600 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 600 may be executed in the order shown in FIG. 6 or, alternatively, in a different order. Process 600 may be implemented by communication apparatus 510 or any suitable UE, network devices or machine type devices. Solely for illustrative purposes and without limitation, process 600 is described below in the context of communication apparatus 510. Process 600 may begin at block 610.

[0107] At block 610, process 600 may involve processor 512 of communication apparatus 510 obtaining at least one security context associated with at least one MNO. The at least one security context may include a first security context associated with a first MNO. Process 600 may proceed from block 610 to block 620.

[0108] At block 620, process 600 may involve processor 512 of communication apparatus 510 applying a security operation to an initial message based on the first security context. Process 600 may proceed from block 620 to block 630.

[0109] At block 630, process 600 may involve processor 512 of communication apparatus 510 transmitting the initial message applied with the security operation to the first MNO for establishing a connection.

[0110] In some implementations, each security context may include at least one of a security algorithm, a key material and a context identification.

[0111] In some implementations, the initial message may include a NAS or a RACH message.

[0112] In some implementations, the security operation may include at least one of a ciphering and an integrity.

[0113] FIG. 7 illustrates an example process 700 in accordance with an implementation of the present disclosure. Process 700 may be an example implementation of above scenarios / schemes, whether partially or completely, with respect to network access management the present disclosure. Process 700 may represent an aspect of implementation of features of network apparatus 520. Process 700 may include one or more operations, actions, or functions as illustrated by one or more of blocks 710 and 720. Although illustrated as discrete blocks, various blocks of process 700 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 700 may be executed in the order shown in FIG. 7 or, alternatively, in a different order. Process 700 may be implemented by network apparatus 520 or any suitable network device (e.g., home network device) or machine type devices. Solely for illustrative purposes and without limitation, process 700 is described below in the context of network apparatus 520. Process 700 may begin at block 710.

[0114] At block 710, process 700 may involve processor 522 of network apparatus 520 determining at least one security context associated with at least one MNO. Process 700 may proceed from block 710 to block 720.

[0115] At block 720, process 700 may involve processor 522 of network apparatus 520 configuring the at least one security context to a UE for establishing a connection.

[0116] In some implementations, each security context may include at least one of a security algorithm, a key material and a context identification.

[0117] FIG. 8 illustrates an example process 800 in accordance with an implementation of the present disclosure. Process 800 may be an example implementation of above scenarios / schemes, whether partially or completely, with respect to network access management the present disclosure. Process 800 may represent an aspect of implementation of features of network apparatus 520. Process 800 may include one or more operations, actions, or functions as illustrated by one or more of blocks 810 to 830. Although illustrated as discrete blocks, various blocks of process 800 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 800 may be executed in the order shown in FIG. 8 or, alternatively, in a different order. Process 800 may be implemented by network apparatus 520 or any suitable network device (e.g., MNO) or machine type devices. Solely for illustrative purposes and without limitation, process 800 is described below in the context of network apparatus 520. Process 800 may begin at block 810.

[0118] At block 810, process 800 may involve processor 522 of network apparatus 520 receiving an initial message from a UE. The initial message may be applied with a security operation based on a security context associated with network apparatus 520. Process 800 may proceed from block 810 to block 820.

[0119] At block 820, process 800 may involve processor 522 of network apparatus 520 obtaining the security context to verify the initial message. Process 800 may proceed from block 820 to block 830.

[0120] At block 830, process 800 may involve processor 522 of network apparatus 520 establishing a connection with the UE based on the initial message.

[0121] In some implementations, each security context may include at least one of a security algorithm, a key material and a context identification.

[0122] In some implementations, the initial message may include a NAS or a RACH message.

[0123] In some implementations, the security operation includes at least one of a ciphering and an integrity.

[0124] FIG. 9 illustrates an example process 900 in accordance with an implementation of the present disclosure. Process 900 may be an example implementation of above scenarios / schemes, whether partially or completely, with respect to network access management the present disclosure. Process 900 may represent an aspect of implementation of features of network apparatus 520. Process 900 may include one or more operations, actions, or functions as illustrated by one or more of blocks 910 to 930. Although illustrated as discrete blocks, various blocks of process 900 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 900 may be executed in the order shown in FIG. 9 or, alternatively, in a different order. Process 900 may be implemented by network apparatus 520 or any suitable network device (e.g., service provider device) or machine type devices. Solely for illustrative purposes and without limitation, process 900 is described below in the context of network apparatus 520. Process 900 may begin at block 910.

[0125] At block 910, process 900 may involve processor 522 of network apparatus 520 determining a QoE item for a UE. Process 900 may proceed from block 910 to block 920.

[0126] At block 920, process 900 may involve processor 522 of network apparatus 520 determining a QoS item associated with the QoE item based on an SLA. Process 900 may proceed from block 920 to block 930.

[0127] At block 930, process 900 may involve processor 522 of network apparatus 520 transmitting the QoS item to an operator for adjusting a communication between the UE and the operator.

[0128] In some implementations, the QoE item may be associated with at least one of a user-intent based request and a user subscription.

[0129] In some implementations, the QoS item may be associated with at least one of a QoS flow, a mobility policy, a traffic scheduling, and a QoS packet forwarding.

[0130] In some implementations, the SLA may be associated with a plurality of mappings between QoE and QoS.

[0131] In some implementations, process 900 may further involve processor 522 of network apparatus 520 determining the SLA with the operator.

[0132] FIG. 10 illustrates an example process 1000 in accordance with an implementation of the present disclosure. Process 1000 may be an example implementation of above scenarios / schemes, whether partially or completely, with respect to network access management the present disclosure. Process 1000 may represent an aspect of implementation of features of network apparatus 520. Process 1000 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1010 and 1020. Although illustrated as discrete blocks, various blocks of process 1000 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 1000 may be executed in the order shown in FIG. 10 or, alternatively, in a different order. Process 1000 may be implemented by network apparatus 520 or any suitable network device (e.g., MNO) or machine type devices. Solely for illustrative purposes and without limitation, process 1000 is described below in the context of network apparatus 520. Process 1000 may begin at block 1010.

[0133] At block 1010, process 1000 may involve processor 522 of network apparatus 520 receiving a QoS item from a service provider. The QoS item may be associated with a QoE item according to an SLA. Process 1000 may proceed from block 1010 to block 1020.

[0134] At block 1020, process 1000 may involve processor 522 of network apparatus 520 adjusting a communication between a UE and the apparatus based on the QoS item.

[0135] In some implementations, the QoE item may be associated with at least one of a user-intent based request and a user subscription.

[0136] In some implementations, the QoS item may be associated with at least one of a QoS flow, a mobility policy, a traffic scheduling, and a QoS packet forwarding.

[0137] In some implementations, the SLA may be associated with a plurality of mappings between QoE and QoS.

[0138] FIG. 11 illustrates an example process 1100 in accordance with an implementation of the present disclosure. Process 1100 may be an example implementation of above scenarios / schemes, whether partially or completely, with respect to network access management of the present disclosure. Process 1100 may represent an aspect of implementation of features of communication apparatus 510. Process 1100 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1110 and 1120. Although illustrated as discrete blocks, various blocks of process 1100 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 1100 may be executed in the order shown in FIG. 11 or, alternatively, in a different order. Process 1100 may be implemented by communication apparatus 510 or any suitable UE, network devices or machine type devices. Solely for illustrative purposes and without limitation, process 1100 is described below in the context of communication apparatus 510. Process 1100 may begin at block 1110.

[0139] At block 1110, process 1100 may involve processor 512 of communication apparatus 510 communicating with a service provider for determining a QoE item and determining a QoS item associated with the QoE item based on an SLA. Process 1100 may proceed from block 1110 to block 1120.

[0140] At block 1120, process 1100 may involve processor 512 of communication apparatus 510 adjusting a communication between the apparatus and an operator based on the QoS item.

[0141] FIG. 12 illustrates an example process 1200 in accordance with an implementation of the present disclosure. Process 1200 may be an example implementation of above scenarios / schemes, whether partially or completely, with respect to network access management of the present disclosure. Process 1200 may represent an aspect of implementation of features of a SAN device (e.g., communication apparatus 510 or network apparatus 520) . Process 1200 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1210 to 1230. Although illustrated as discrete blocks, various blocks of process 1200 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 1200 may be executed in the order shown in FIG. 12 or, alternatively, in a different order. Process 1200 may be implemented by any suitable UE, network devices or machine type devices (e.g., a device having a SAN controller) . Solely for illustrative purposes and without limitation, process 1200 is described below in the context of the SAN device. Process 1200 may begin at block 1210.

[0142] At block 1210, process 1200 may involve a processor of the SAN device determining a service requirement associated with a UE. Process 1200 may proceed from block 1210 to block 1220.

[0143] At block 1220, process 1200 may involve the processor of the SAN device determining an operator from a plurality of operators based on the service requirement. Process 1200 may proceed from block 1220 to block 1230.

[0144] At block 1230, process 1200 may involve the processor of the SAN device instructing the UE to switch to the operator from another operator.

[0145] In some implementations, the UE may be capable of establishing a connection to each of the plurality of operators.

[0146] In some implementations, process 1200 may involve the processor of the SAN device receiving a request from a service provider for determining the operator. The request may be associated with the service requirement.

[0147] In some implementations, process 1200 may involve the processor of the SAN device receiving a request to modify a control policy by setting conditions for determining the operator.

[0148] In some implementations, the SAN device may include a SAN controller configured with the plurality of operators.

[0149] In some implementations, the SAN device may include a service provider having a SAN controller, or the UE having the SAN controller.

[0150] FIG. 13 illustrates an example process 1300 in accordance with an implementation of the present disclosure. Process 1300 may be an example implementation of above scenarios / schemes, whether partially or completely, with respect to network access management of the present disclosure. Process 1300 may represent an aspect of implementation of features of communication apparatus 510. Process 1300 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1310 to 1330. Although illustrated as discrete blocks, various blocks of process 1300 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 1300 may be executed in the order shown in FIG. 13 or, alternatively, in a different order. Process 1300 may be implemented by communication apparatus 510 or any suitable UE, network devices or machine type devices. Solely for illustrative purposes and without limitation, process 1300 is described below in the context of communication apparatus 510. Process 1300 may begin at block 1310.

[0151] At block 1310, process 1300 may involve processor 512 of communication apparatus 510 reporting service-related information to a SAN controller for generating a service requirement associated with a UE. Process 1300 may proceed from block 1310 to block 1320.

[0152] At block 1320, process 1300 may involve processor 512 of communication apparatus 510 receiving an operator switch instruction from the SAN controller. The operator switch instruction may be determined based on the service requirement. Process 1300 may proceed from block 1320 to block 1330.

[0153] At block 1330, process 1300 may involve processor 512 of communication apparatus 510 switching from an operator to another operator based on the operator switch instruction.

[0154] In some implementations, communication apparatus 510 may be capable of establishing a connection to each of a plurality of operators.

[0155] In some implementations, process 1300 may further involve processor 512 of communication apparatus 510 requesting the SAN controller for modifying a control policy by setting conditions for determining the operator switch instruction.

[0156] In some implementations, communication apparatus 510 may include the SAN controller.

[0157] FIG. 14 illustrates an example process 1400 in accordance with an implementation of the present disclosure. Process 1400 may be an example implementation of above scenarios / schemes, whether partially or completely, with respect to network access management of the present disclosure. Process 1400 may represent an aspect of implementation of features of communication apparatus 510. Process 1400 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1410 to 1440. Although illustrated as discrete blocks, various blocks of process 1400 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 1400 may be executed in the order shown in FIG. 14 or, alternatively, in a different order. Process 1400 may be implemented by communication apparatus 510 or any suitable UE, network devices or machine type devices. Solely for illustrative purposes and without limitation, process 1400 is described below in the context of communication apparatus 510. Process 1400 may begin at block 1410.

[0158] At block 1410, process 1400 may involve processor 512 of communication apparatus 510 initiating a service via an NTN. Process 1400 may proceed from block 1410 to block 1420.

[0159] At block 1420, process 1400 may involve processor 512 of communication apparatus 510 determining a container identification associated with the service. Process 1400 may proceed from block 1420 to block 1430.

[0160] At block 1430, process 1400 may involve processor 512 of communication apparatus 510 transmitting the container identification to an operator via the NTN for determining a container associated with the container identification. Process 1400 may proceed from block 1430 to block 1440.

[0161] At block 1440, process 1400 may involve processor 512 of communication apparatus 510 utilizing the service based on the container.

[0162] In some implementations, process 1400 may further involve processor 512 of communication apparatus 510 determining a plurality of mappings between services and container identifications.

[0163] In some implementations, the container may include at least one of: (1) the container identification, (2) a QoS profile, (3) an access-type specific service policy, and (4) authorization data.

[0164] In some implementations, the QoS profile may include at least one of: (1) a bandwidth, (2) a latency, (3) a reliability, and (4) an availability.

[0165] In some implementations, the authorization data may include at least one of a user identity token and a service access token.

[0166] In some implementations, the service may be utilized based on the QoS profile of the container.

[0167] FIG. 15 illustrates an example process 1500 in accordance with an implementation of the present disclosure. Process 1500 may be an example implementation of above scenarios / schemes, whether partially or completely, with respect to network access management the present disclosure. Process 1500 may represent an aspect of implementation of features of network apparatus 520. Process 1500 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1510 to 1530. Although illustrated as discrete blocks, various blocks of process 1500 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 1500 may be executed in the order shown in FIG. 15 or, alternatively, in a different order. Process 1500 may be implemented by network apparatus 520 or any suitable network device (e.g., MNO) or machine type devices. Solely for illustrative purposes and without limitation, process 1500 is described below in the context of network apparatus 520. Process 1500 may begin at block 1510.

[0168] At block 1510, process 1500 may involve processor 522 of network apparatus 520 receiving a container identification from a UE via an NTN for initiating a service. Process 1500 may proceed from block 1510 to block 1520.

[0169] At block 1520, process 1500 may involve processor 522 of network apparatus 520 determining a container associated with the container identification. Process 1500 may proceed from block 1520 to block 1530.

[0170] At block 1530, process 1500 may involve processor 522 of network apparatus 520 providing the service based on the container.

[0171] In some implementations, process 1500 may further involve processor 522 of network apparatus 520 determining a plurality of mappings between services and container identifications.

[0172] In some implementations, the container may include at least one of: (1) the container identification, (2) a QoS profile, (3) an access-type specific service policy, and (4) authorization data.

[0173] In some implementations, the service may be provided based on the QoS profile of the container. Additional Notes

[0174] The herein-described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "operably connected" , or "operably coupled" , to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable" , to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0175] Further, with respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.

[0176] Moreover, it will be understood by those skilled in the art that, in general, terms used herein, and especially in the appended claims, e.g., bodies of the appended claims, are generally intended as “open” terms, e.g., the term “including” should be interpreted as “including but not limited to, ” the term “having” should be interpreted as “having at least, ” the term “includes” should be interpreted as “includes but is not limited to, ” etc. It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to implementations containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an, " e.g., “a” and / or “an” should be interpreted to mean “at least one” or “one or more; ” the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number, e.g., the bare recitation of "two recitations, " without other modifiers, means at least two recitations, or two or more recitations. Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. In those instances where a convention analogous to “at least one of A, B, or C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. It will be further understood by those within the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B. ”

[0177] From the foregoing, it will be appreciated that various implementations of the present disclosure have been described herein for purposes of illustration, and that various modifications may be made without departing from the scope and spirit of the present disclosure. Accordingly, the various implementations disclosed herein are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Claims

1.A method, comprising:obtaining, by a processor of an apparatus, at least one security context associated with at least one Mobile Network Operator (MNO) , wherein the at least one security context includes a first security context associated with a first MNO;applying, by the processor, a security operation to an initial message based on the first security context; andtransmitting, by the processor, the initial message applied with the security operation to the first MNO for establishing a connection.2.The method of Claim 1, wherein each security context includes at least one of a security algorithm, a key material and a context identification.3.The method of Claim 1, wherein the initial message includes a Non-Access Stratum (NAS) or a Random Access Channel (RACH) message.4.The method of Claim 1, wherein the security operation includes at least one of a ciphering and an integrity.5.A method, comprising:determining, by a processor of an apparatus, at least one security context associated with at least one Mobile Network Operator (MNO) ; andconfiguring, by the processor, the at least one security context to a User Equipment (UE) for establishing a connection.6.The method of Claim 5, wherein each security context includes at least one of a security algorithm, a key material and a context identification.7.A method, comprising:receiving, by a processor of an apparatus, an initial message from a User Equipment (UE) , wherein the initial message is applied with a security operation based on a security context associated with the apparatus;obtaining, by the processor, the security context to verify the initial message; andestablishing, by the processor, a connection with the UE based on the initial message.8.The method of Claim 7, wherein each security context includes at least one of a security algorithm, a key material and a context identification.9.The method of Claim 7, wherein the initial message includes a Non-Access Stratum (NAS) or a Random Access Channel (RACH) message.10.The method of Claim 7, wherein the security operation includes at least one of a ciphering and an integrity.11.A method, comprising:determining, by a processor of an apparatus, a Quality of Experiences (QoE) item for a User Equipment (UE) ;determining, by the processor, a Quality of Service (QoS) item associated with the QoE item based on a Service Level Agreement (SLA) ; andtransmitting, by the processor, the QoS item to an operator for adjusting a communication between the UE and the operator.12.The method of Claim 11, wherein the QoE item is associated with at least one of a user-intent based request and a user subscription.13.The method of Claim 11, wherein the QoS item is associated with at least one of a QoS flow, a mobility policy, a traffic scheduling, and a QoS packet forwarding.14.The method of Claim 11, wherein the SLA is associated with a plurality of mappings between QoE and QoS.15.The method of Claim 11, further comprising:determining, by the processor, the SLA with the operator.16.A method, comprising:receiving, by a processor of an apparatus, a Quality of Service (QoS) item from a service provider, wherein the QoS item is associated with a Quality of Experiences (QoE) item according to a Service Level Agreement (SLA) ; andadjusting, by the processor, a communication between a User Equipment (UE) and the apparatus based on the QoS item.17.The method of Claim 16, wherein the QoE item is associated with at least one of a user-intent based request and a user subscription.18.The method of Claim 16, wherein the QoS item is associated with at least one of a QoS flow, a mobility policy, a traffic scheduling, and a QoS packet forwarding.19.The method of Claim 16, wherein the SLA is associated with a plurality of mappings between QoE and QoS.20.A method, comprising:communicating, by a processor of an apparatus, with a service provider for determining a Quality of Experiences (QoE) item and determining a Quality of Service (QoS) item associated with the QoE item based on a Service Level Agreement (SLA) ; andadjusting, by the processor, a communication between the apparatus and an operator based on the QoS item.21.A method, comprising:determining, by a processor of an apparatus, a service requirement associated with a User Equipment (UE) ;determining, by the processor, an operator from a plurality of operators based on the service requirement; andinstructing, by the processor, the UE to switch to the operator from another operator.22.The method of Claim 21, wherein the UE is capable of establishing a connection to each of the plurality of operators.23.The method of Claim 21, further comprising:receiving, by the processor, a request from a service provider for determining the operator, wherein the request is associated with the service requirement.24.The method of Claim 21, further comprising:receiving, by the processor, a request to modify a control policy by setting conditions for determining the operator.25.The method of Claim 21, wherein the apparatus includes a Service Area Network (SAN) controller configured with the plurality of operators.26.The method of Claim 21, wherein the apparatus includes a service provider having a Service Area Network (SAN) controller, or the UE having the SAN controller.27.A method, comprising:reporting, by a processor of an apparatus, service-related information to a Service Area Network (SAN) controller for generating a service requirement associated with a User Equipment (UE) ;receiving, by the apparatus, an operator switch instruction from the SAN controller, wherein the operator switch instruction is determined based on the service requirement; andswitching, by the apparatus, from an operator to another operator based on the operator switch instruction.28.The method of Claim 27, wherein the apparatus is capable of establishing a connection to each of a plurality of operators.29.The method of Claim 27, further comprising:requesting, by the processor, the SAN controller for modifying a control policy by setting conditions for determining the operator switch instruction.30.The method of Claim 27, wherein the apparatus includes the SAN controller.31.A method, comprising:initiating, by a processor of an apparatus, a service via a Non-Terrestrial Network (NTN) ;determining, by the processor, a container identification associated with the service;transmitting, by the processor, the container identification to an operator via the NTN for determining a container associated with the container identification; andutilizing, by the processor, the service based on the container.32.The method of Claim 31, further comprising:determining, by the processor, a plurality of mappings between services and container identifications.33.The method of Claim 31, wherein the container includes at least one of:the container identification,a Quality of Service (QoS) profile,an access-type specific service policy, andauthorization data.34.The method of Claim 33, wherein the QoS profile includes at least one of:a bandwidth,a latency,a reliability, andan availability.35.The method of Claim 33, wherein the authorization data includes at least one of a user identity token and a service access token.36.The method of Claim 33, wherein the service is utilized based on the QoS profile of the container.37.A method, comprising:receiving, by a processor of an apparatus, a container identification from a User Equipment (UE) via a Non-Terrestrial Network (NTN) for initiating a service;determining, by the processor, a container associated with the container identification; andproviding, by the processor, the service based on the container.38.The method of Claim 37, further comprising:determining, by the processor, a plurality of mappings between services and container identifications.39.The method of Claim 37, wherein the container includes at least one of:the container identification,a Quality of Service (QoS) profile,an access-type specific service policy, andauthorization data.40.The method of Claim 39, wherein the service is provided based on the QoS profile of the container.

Images