DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/06/2026 has been entered.
Information Disclosure Statement
The information disclosure statements (IDSs) filed 04/10/2026 and 06/09/2026 were filed after the Request for Continued Examination dated 04/06/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Amendment
The amendment to the claims filed on 03/23/2026 complies with the requirements of 37 CFR 1.121(c) and has been entered. Claims 1, 29, 34-36, 42, and 58 are amended. Claim 115 is new. Claims and 2-28, 43, 57, 59-114 are cancelled.
Response to Arguments
Applicant's Arguments/Remarks filed 03/23/2026 (hereinafter Resp.) have been fully considered as follows.
Regarding the argument that “using an RSRP measurement to choose between two uplink carriers is not the same as, and does not teach or suggest that ‘selecting between a two-step service-based random access procedure and a four-step service-based random access procedure ... based at least in part on whether a measured reference signal received power satisfies a reference signal received power threshold that is dedicated to the priority level [of the service],’ as recited in amended independent claim 1” – See Resp., p.15:¶2, every term in the claim language is given the broadest reasonable interpretation in light of the Specification as understood by one of ordinary skills in the art. Here, the Specification states that “each dedicated RSRP threshold . . . may be the same, or partially the same, and each dedicated RSRP threshold may be the same . . . [as] the common RSRP threshold” – See [¶0082]. That is, even if the RSRP threshold in the claim language gets the attribute “dedicated” that attribute must be interpreted in light of the Specification and one reasonable interpretation is that the dedicated RSRP threshold is the common RSRP threshold used in RACH operations as taught in the 3GPP standards and in the references cited by the Office Action. The identification of the “dedicated RSRP threshold” with the “common RSRP threshold” is motivated also by their functional identity – See id. (stating: “[i]f the measured RSRP between UE 115-a and base station 105-a is greater than the dedicated RSRP threshold, UE 115-a may select the 2-step slice-based RACH procedure,” i.e., the “dedicated RSRP threshold” has the same role as the common one described by standards; furthermore, a “UE 115-a may fall back to the common RSRP value to select a slice-based RACH procedure,” i.e., the common RSRP may be used in any case instead of the “dedicated RSRP threshold”, including “If the network slice is not associated with a dedicated RSRP threshold in the message, UE 115-a may use the common RSRP to select a slice-based RACH procedure”); see also 3GPP TS 38.331 V16.3.1 (2021-01), “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 16),” published January 6, 2021 (hereinafter 3GPP TS 38.331), specifying at page 549-51, the Information Element (IE) RACH-ConfigCommon, including a common RSRP threshold parameter rsrp-ThresholdSSB, further specifying RACH-ConfigDedicated IE, at page 554-58, including a dedicated, target specific, rsrp-ThresholdCSI-RS parameter, i.e., the standards offer means to configure both common and dedicated RSRP thresholds to select a slice-based RACH procedure.
Applicant further argues specifically that “Kang fails to describe any RSRP threshold ‘that is dedicated to the priority level’ of ‘a service to be accessed by the UE,’ that is used to select ‘between a two-step service-based random access procedure and a four-step service-based random access procedure’” – See Resp., p.15:¶2. Examiner respectfully disagrees and points to Kang disclosing “independent system access configuration information for each slice/service” – See [¶0093] and Fig. 6B showing a dedicated RACH-ConfigCommon per service/slice which inherently include a dedicated RSRP threshold parameter rsrp-ThresholdSSB for each service/slice as provided by the 3GPP specification. In addition, “A person of ordinary skill in the art is also a person of ordinary creativity, not an automaton.” KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 421, 82 USPQ2d 1385, 1397 (2007), and “in many cases a person of ordinary skill will be able to fit the teachings of multiple patents together like pieces of a puzzle.” Id. at 420, 82 USPQ2d 1397. Therefore, taking into account “the inferences and creative steps that a person of ordinary skill in the art would employ.” Id. at 418, 82 USPQ2d at 1396, Applicant’s argument that “a reference signal received power threshold that is dedicated to the priority level [of the service]” would qualify as a novel feature distinguishing the present Application from prior art, is unpersuasive.
Claim Objections
Claims 32-37 are objected to under 37 CFR 1.75 as being a substantial duplicate of Amended Claim 29. When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m).
Claim 115 is objected to because of the following informalities: the claim language recites “a first priority level” or “a second priority level” only to require specific limitations on both the first priority level and the second priority level. Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 29-42, 44-51 and 55-56, 58, and 115, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Kang et al., U.S. Patent Application No. 2023/0292372 (hereinafter Kang), and further in view of Report of 3GPP TSG RAN WG2 meeting #112-e, R2-2100001, Agenda Item: 8.8.3 "Slice based RACH configuration or access barring," (hereinafter 3GPP R2-2100001 Report) and Tdocs contributed to the Agenda Item and referenced therein, published November 2020.
Regarding Amended Claim 1, Kang teaches a method for wireless communications at a user equipment (UE) (“method for a terminal to process network slice-based system access configuration information in a wireless communication system” – See [¶0010], and “the disclosure describes embodiments using terms used in some communication standards ( e.g., 3rd generation partnership project (3GPP))” – See [¶0048]), comprising:
receiving, from a base station, a random access configuration for performance, by the UE, of random access with a physical network (“system access configuration information of the terminal may be transmitted while being included in a system broadcast message SIB1” and may include “the InitialUplinkBWP information may include rach-ConfigCommon information, and the rach-ConfigCommon information may include system access configuration information of a general terminal” – See [¶0088] and TABLE 2 at page 6-7, indicating parameters for RACH on the physical network including a common rsrp-ThresholdSSB and RA prioritization based on Access Identities as indicated by ra-PrioritizationForAI-r16 and based on supported slice/service as shown in TABLE 4, at page 8, whereby “independent system access configuration information for each slice/service” is provided before the UE has first accessed the slice/service when “the InitialUplinkBWP information may include at least one or a combination of rach-ConfigCommonSliceA information, rachConfigCommonSliceB information to rachConfigCommonSliceN information indicating system access configuration information of terminals interested in a slice/service A, a slice/service B, or a slice/service N. The rach-ConfigCommonSliceA information, rach-ConfigCommonSliceB information to rach-ConfigCommonSliceN information may be configured independently of the rachConfigCommon information of Table 2” – See [¶0093], i.e., a per slice/service dedicated rach-ConfigCommonSliceN configuration information contains the standard RACH-Config Common parameters specific to a slide, including priority thresholds, 2-spet or 4-step RA procedure, etc.; furthermore, if the UE is already connected to an AMF/core, “the dedicated RRC signaling may provide slice specific RACH-Dedicated configuration information” whereby “RACH-Dedicated configuration information may configure different RACH resources to one or multiple slices/service NSSAI in the same manner as that of the case of RACHConfigCommon of FIGS. 6A and 6B” – See [¶0105]; see also 3GPP TS 38.331 V16.3.1 (2021-01), “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 16),” published January 6, 2021 (hereinafter 3GPP TS 38.331), specifying at page 549-51, the Information Element (IE) RACH-ConfigCommon, used to specify the cell specific random-access parameters, including “ra-Prioritization Parameters which apply for prioritized random access procedure on any UL BWP of SpCell for specific Access Identities (see TS 38.321 [3], clause 5.1.1a),” including the ra-PrioritizationForAI parameter that “[i]ndicates whether the field ra-Prioritization-r16 applies for Access Identities. The first/leftmost bit corresponds to Access Identity 1, the next bit corresponds to Access Identity 2. Value 1 indicates that the field ra-Prioritization-r16 applies otherwise the field does not apply (see TS 23.501 [32]),” the common rsrp-Threshold parameter for performing RA, and further specifies; cf. the IE RACH-ConfigDedicated specified at page 554-57, used to specify the dedicated random access parameters to access a target cell (e.g., offering the service/slice A, B…N infra) including a dedicated rsrp-ThresholdCSI-RS parameter; see 3GPP TS 23.501 V16.7.0 (2020-12), “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16)”, published January 6, 2021 (hereinafter 3GPP TS 23.501) describing in § 5.2.5, at page 72, access control and barring including the “Unified Access Control functionality for 3GPP access specified in TS 22.261” and in §5.15.2 identification and selection of a Network Slice using the S-NSSAI and the NSSAI, including information in TABLE 1 at page 6 of Kang; see also TABLE 7, at page 13, referencing 3GPP TS 22.261 V17.5.0 (2020-12) Technical Specification Group Services and System Aspects; Service requirements for the 5G system; Stage 1 (Release 17)” (hereinafter 3GPP TS 22.261) describing, in §6.22 at page 34-36 the Unified Access Control, showing in Table 6.22.2.2-1 the Access Identities configured to the UE based on the service accessed, and in Table 6.22.2.3-1 the Access Categories based on UE’s access service attempt;);
identifying a service to be accessed by the UE, the service supported by a logical network associated with the physical network (“An access category to be configured to each slice/ service may, for example, use values of 32 to 63 reserved for use by the operator” and “An access category value for a slice/service configured by the service provider may be transmitted to the terminal” – See [¶0168] and TABLE 8 at page 15, e.g., “a network data collection and analysis function (NWDAF), which is a network function that provides a function of analyzing and providing data collected in a 5G network” and outputs “results to unspecified network functions (NFs), and the analysis results may be used independently in each NF,” such as core NF, RAN NF, AMF NF, whereby NFs and the associated resources support network slices1,2 a logical networks, as shown in Figure 4.1.6.1 reproduced herein and referenced in Footnote 1 infra, so that the “network may provide one or multiple vertical slices and service,” e.g., as described in TABLE 1 showing “slice/service type (SST) values of the corresponding slices/services” – See [¶0085]; furthermore, “[t]he network slice selection assistance information (NSSAI) . . . may indicate a network slice/service, and be composed of a slice/service type (SST) or an SST and a slice differentiator (SD)” – See [¶0091] and Table 5 at page 9; see also Table 3 reproducing the IE S-NSSAI specified by 3GPP TS 38.331, at page 629-30);
PNG
media_image1.png
356
746
media_image1.png
Greyscale
Figure 4.1.6.1: Examples of Network Slice as a Service (NSaaS) being utilized to deliver communication services to end customers (from 3GPP TS 28.530, at page11)
electing a service-based random access procedure type based at least in part on the random access configuration and the service to be accessed by the UE (“system access configuration information (random access configuration) may be configured for each slice/service” – See [¶0086], e.g., “the InitialUplinkBWP information may include at least one or a combination of rach-ConfigCommonSliceA information, rach-ConfigCommonSliceB information to rach-ConfigCommonSliceN information indicating system access configuration information of terminals interested in a slice/service A, a slice/service B, or a slice/service N,” i.e., “independent system access configuration information for each slice/service” – See [¶0093] and when “the system operates one or multiple network slices/services, the system may apply and operate separate access control to each network slice/service,” because “the system may form system access control configuration information including each slice/service NSSAI to which a UAC parameter is to be applied” – See [¶0148] e.g., “FIG. 11 illustrates a constitution of slice/service based system access control configuration (unified access control (UAC)) information” – See [¶0149] and TABLE 8, at page 15, a simplified version of Table 6.22.2.3-1 Access Categories in § 6.22, 3GPP TS 22.261, at page 34-36, describing the Unified Access Control based on Access Categories and Access Identities; “slice/service-based system access configuration information . . . may configure different RACH resources for one or multiple slices/services” – See [¶0094] for contention-free access, whereby “the RACH resource configured to one or multiple slices/services in which the terminal acquires based on slice/service identification information of interest thereof may include at least one of a RACH occasion, a PRACH preamble, or a combination thereof” – See [¶0096]; in addition, “[t]he slice/service-based system access configuration information may be provided to a terminal in a radio resource control (RRC) connection state through dedicated RRC signaling, wherein the dedicated RRC signaling may provide slice specific RACH-Dedicated configuration information” which “may configure different RACH resources to one or multiple slices/service NSSAI” – See [¶0105]; therefore, if not connected to the network, the terminal selects e.g., for the service/slice ‘N’ the specific RACH resource configuration and the RA procedure type using parameters indicated in the dedicated configuration information rach-ConfigCommonSliceN; and if RRC connected uses slice specific RACH-Dedicated configuration information, whereby if RACH resources are slice/service specific then there is contention-free access and 2-step RA procedure may apply – See, e.g., 3GPP 38.331, specifying, at page 554-58, RACH-ConfigDedicated IE “used to specify the dedicated random access parameters” including cfra-TwoStep “Parameters for contention free 2-step random access type to a given target cell” and ra-PrioritizationTwoStep “Parameters which apply for prioritized 2-step random access type procedure to a given target cell (see TS 38.321 [3], clause 5.1.1)”; and further at page 551-54, the RACH-ConfigCommonTwoStepRA IE “used to specify cell specific 2-step random-access type parameters” including msgA-RSRP-Threshold discussed infra),
wherein the selecting comprises selecting between a two-step service-based random access procedure and a four-step service-based random access procedure based at least in part on whether a priority level of the service satisfies a threshold priority level (“The terminal may determine S-NSSAI corresponding to the MT service slice based on allowed S-NSSAI list information configured by the network, and perform an MT service access procedure with reference to other configuration information (frequency, cell, priority) corresponding to the S-NSSAI” – See [¶0174] whereby “Slice/service-based system access configuration information transmitted through the system broadcast message formed in FIGS. 6A and 6B uses the same RACH resource, but may be configured in a manner that applies different prioritization parameters for each slice/service” including “power ramping step . . . as illustrated in Table 4” – See [¶0097] and TABLE 4, at page 8, showing the power step parameter powerRampingStepHighPriority in dB applied for prioritized random access procedure to a specific slice/service; see also 3GPP TS 38.331, specifying, at page 550 that ra-prioritization parameters “apply for prioritized random access procedure on any UL BWP of SpCell for specific Access Identities (see TS 38.321 [3], clause 5.1.1a)” and ra-PrioritizationForAI “Indicates whether the field ra-Prioritization-r16 applies for Access Identities. The first/leftmost bit corresponds to Access Identity 1, the next bit corresponds to Access Identity 2. Value 1 indicates that the field ra-Prioritization-r16 applies otherwise the field does not apply (see TS 23.501 [32]),” i.e., a priority level of the service must satisfy a threshold priority level for the slice/service type, based on an Access Identity and/or Access Category – See Table 6.22.2.2-1 and Table 6.22.2.3-1, 3GPP 22.261, at page 34-36, supra, to which the UE attempts access before obtaining the dedicated RACH-Dedicated configuration information for the slice wherein 2-step RA type contention free random access or 4-step RA type have been explicitly provided in rach-ConfigDedicated – See 3GPP 38.331, at page 557-58; However, a person of ordinary skills in the art would appreciate that if the higher the powerRampingStepHighPriority in dB is, the faster the UE would gain access to the slice/service therefore a 2-step RA procedure could be used– See 3GPP R2-2009974 infra),
and further based at least in part on whether a measured reference signal received power satisfies a reference signal received power threshold that is dedicated to the priority level (“The network slice selection assistance information of interest configured to the terminal may be composed of only an SST or a combination of an SST and an SD” and “[a]ccording to identification information configured to the terminal and identification information configured to system access configuration information for each slice/service, an operation for the terminal to perform system access may vary, as illustrated in Table 5” – See [¶0107] and TABLE 5 at page 9-10 indicating that when the UE provides full slice assistance information, i.e. SST+SD, the network will provide “slice specific configuration (rach-ConfigCommonSlice) for access,” and rach-ConfigCommonSliceX contains dedicated/slice specific RACH parameters, including rsrp-ThresholdSSB and ra-PrioritizationForAccessidentity, as shown in TABLE 2 at page 6-7; therefore, “If system access configuration information on a slice/service of interest is provided in the selected uplink, the terminal may determine to perform a system access procedure using the corresponding information” – See [¶0123] including determining whether the measured RSRP value on the received SSBs is higher than the dedicated thresholds rsrp-ThresholdSSB for 4-step RA, msgA-RSRP-ThresholdSSB for 2-step RA, and msgA-RSRP-Threshold when both 2-step and 4-step RA are available for the UE to access the slice/service – See TABLE 2 at page 6-7, and 3GPP 38.331 specifying RACH-ConfigCommon and RACH-ConfigCommonTwoStepRA at page 548-54; see also 3GPP TS 38.321 V16.3.0 (2020-12), “Technical Specification Group Radio Access Network; NR; Medium Access Control (MAC) protocol specification (Release 16)” (hereinafter 3GPP TS 38.321) providing, at page 16 that msgA-RSRP-Threshold is “an RSRP threshold for selection between 2-step RA type and 4-step RA type when both 2-step and 4-step RA type Random Access Resources are configured in the UL BWP”; therefore, both the different prioritization parameters for each slice/service and the dedicated RSRP-Threshold in the slice specific RACH-ConfigCommonSliceX determine the type of RA procedure to access the specific slice/service, and wherein:
the two-step service-based random access procedure is selected when the priority level is greater than the threshold priority level – See 3GPP R2-2009974 infra explaining the combination between the higher priority of a slice, e.g., a critical slice, and the need for faster access of the UE to the slice, e.g., by using the 2-step RA procedure instead of a 4-step RA procedure,
and when the measured reference signal received power is greater than the reference signal received power threshold dedicated to the priority level (as explained supra regarding slice specific msgA-RSRP-Threshold; see also 3GPP R2-2009974 infra), and
the four-step service-based random access procedure is selected when the priority level is less than the threshold priority level (following the 3GPP R2-2009974 disclosure infra, only high priority slices are associated with 2-step RA for faster access, therefore 4-step RA is associated with lower priority slices because they do not need faster access, whereby the threshold priority level may be operator dependant based on a chosen Access Category value, as taught in TABLE 8 of Kang, at page 15, an operation that would be obvious to one of ordinary skills in the art) and
when the measured reference signal received power is less than the reference signal received power threshold dedicated to the priority level (following the 3GPP R2-2009974 disclosure infra, “UEs not meeting its slice-defined RSRP threshold would fallback to 4-Step RACH”); and
performing a service-based random access procedure in accordance with the service-based random access procedure type (“If it is determined that system access configuration information on a slice/service of interest of the terminal is configured to the selected [N/]SUL, the terminal may perform a system access procedure using system access configuration information on a slice/service in the selected [N/]SUL” – See [¶0128], e.g., “perform an MT service access procedure with reference to other configuration information (frequency, cell, priority) of the corresponding slice” – See [¶0175]).
However, as noted above, Kang does not explicitly teach 2-step/4-step RA procedure when the priority level is greater/less than a threshold priority level. 3GPP R2-2100001 Report summarizes in § 8.8.3, at page 253, the agreements following discussion of proposals on slice-based RACH configuration or access barring including that “Slice-specific RACH parameters prioritization can be configured per slice” and references the following contributions regrading prioritization:
3GPP R2-2100001 Report references R2-2009806, Title: “Consideration on the slice specific RACH configuration,” Source: ZTE Corporation, Sanechips, published November 2020 (hereinafter 3GPP R2-2009806) wherein, in § 2.1, at page2-3, describes the association between RACH resources and operator defined access categories can be broadcast in system information to link the RACH resources with slices implicitly, like described in Kang where the UE may learn slice specific RACH resources and RA configuration based on Access Category. The proposal further discloses, in § 2.2, at page 3, that “since the slice(s) can be associated with the operator defined access categories, configuring RA prioritization for access categories can be used to prioritize random access for slices without exposing the NSSAI/S-NSSAI (or parts of it) directly in system information” referencing the RA-Prioritization IE described in Kang and in 3GPP TS 38.331, as explained supra. The proposal further discloses, at page 4, a new RA-Prioritization IE, the ra-PrioritizationForAC so that “RA prioritization (including powerRampingStepHighPriority and scalingFactorBI) for operator defined access categories can be introduced in system information to prioritize random access for certain slices implicitly” through RACH-ConfigCommon as well as RACH-ConfigCommonTwoStepRA IEs discussed in Kang as slice-specific IEs and parameters, and specified in 3GPP TS 38.331 supra.
3GPP R2-2100001 Report also references R2-2009199, Title: “Consideration of slice based RACH,” Source: Intel Corporation, published November 2020 (hereinafter 3GPP R2-2009199 ) that proposes, at page 2, to use the same mechanism for slice prioritization as in 4-step and 2-step RA procedures (“In 4-step and 2-step RACH, RA prioritization with the configured parameters powerRampingStepHighPriority and scalingFactorBI is supported for beam failure recovery and handover scenario in order to reduce the latency of random access. This is also extended to become applicable to MPS and MCS for RRC establishment and resumption in Rel-16. As baseline, these same RA prioritization parameters can be applied also for critical slice”) whereby it is proposed to “Broadcast the operator defined access categories with their corresponding RA prioritization in SIB” and “UE AS selects the corresponding RA prioritization based on the operator defined access category provided by NAS for the RA procedure triggered by RRC establishment and resumption from RRC”).
Therefore, both 3GPP R2-2009806 and 3GPP R2-2009199 propose the priority of a slice for RA procedure is given by the Access Category of that slice/service, in accord with the method described in Kang.
In addition, 3GPP R2-2100001 Report also references R2-2009974, Title:” RACH enhancements to enable UE fast access to the intended slice,” Source: NEC, published November 2020 (hereinafter 3GPP R2-2009974), wherein at page 1, distinguishes between RACH prioritization, a threshold that assures “Better probability of early successful RA for higher priority UEs (less backoff and higher power ramping)” and “fast access, even in case of success,” to a slice. 3GPP R2-2009974, at page 2, further proposes to use “2-Step RACH . . . introduced in Release 16 with, among other goals, to allow UEs fast access to PUSCH resources” specifically the mechanism based on msgA-rsrp-Threshold described in 3GPP TS 38.321 supra, that “would effectively allow faster access to the intended slice for high priority slices. This solution also allows fine tuning of slices priorities and enables RACH isolation. Indeed, UEs not meeting its slice-defined RSRP threshold would fallback to 4-Step RACH,” whereby “slice-based RSRP thresholds [are used] for selection between 2-Step and 4-Step RACH.”
Yet another contribution referenced in 3GPP R2-2100001 Report in a separate Agenda Item of the same RAN2 meeting, R2-2010232, Title: “Title: 2-step RACH and 4-step RACH selection criteria for SDT,” Source: Xiaomi, published November 2020 (hereinafter 3GPP R2-2010232) explains, at page 1, that “firstly UE should determine the RA type, then transmit preamble. As known the criterion of RA type selection has been defined in R16, if UE is configured with 2-step RACH and 4-step RACH by NW, the UE should select the 2-step RACH type if conditions such as e.g. the RSRP is fulfilled. Based on this analyze the RA type selection for UL data transmission should follow the criterion of RA type selection between 2-step RACH and 4-step RACH as defined in R16.”
3GPP R2-2100001 Report also references changes to both 3GPP TS 38.331 and 3GPP TS 38.321 in view of 2-step RA procedures, specifically R2-2011062, 38.331 CR 2149, Title: “Corrections to 2-Step RA,” Source: Ericsson, Huawei, published November 2020; and R2-2009969, 38.321 CR 0953, Title: “Parameter corrections to 2-Step RA,” Source: Ericsson, published October 2020. All references to 3GPP TS 38.331 and 3GPP TS 38.321 include these corrections.
In sum, contributions referenced in the 3GPP R2-2100001 Report disclose that: (1) Access Category of a slice is an indication (to the UE) of a slice priority level potentially as a new IE ra-PrioritizationForAC – See 3GPP R2-2009806; (2) the same RA-prioritization parameters, i.e., powerRampingStepHighPriority and scalingFactorBI, apply to ra-PrioritizationForAC IE as for ra-Prioritization and ra-PrioritizationForAI – See id.; (3) slices with higher priority should provide faster access, e.g., the UE could proceed with 2-step RA if the received RSRP is above the slice specific msgA-rsrp-Threshold – See 3GPP R2-2009199.
Thus, Kang and 3GPP R2-2100001 Report each discloses slice specific RACH configuration IEs received by the UE via system information (SIB) and/or RRC, and a mechanism to prioritize among slices based on UAC Access Categories but using the same powerRampingStepHighPriority and scalingFactorBI parameters as specified by the 3GPP standards. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the selection of a 2-step RA procedure for accessing the slice/service, using the same RSRP threshold condition as specified by the standards, only with a slice specific threshold, as disclosed by 3GPP R2-2100001 Report, could have been combined with the step of the UE selecting an access procedure with reference to other configuration information (frequency, cell, priority) of the corresponding slice, as taught in Kang, because both use slice specific priorities and slice specific RACH-Config parameters. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination through techniques known in the art. Finally, the combination achieves the predictable result of allowing fast access to a high priority slice and a finer granularity prioritization of slices, as taught in 3GPP R2-2100001 Report references.
Therefore, Amended Claim 1 is obvious over Knag in view of 3GPP R2-2100001 Report.
Regarding Amended Claim 29, Kang further teaches an apparatus for wireless communications at a user equipment (UE) (“a terminal acquires network slice-based system access configuration information and performs a system access procedure in a wireless communication system” – See [¶0010]), comprising: a processor (“the terminal 120 includes a communication unit 310, a storage 320, and a controller 330” whereby “the controller 330 may include one or more processors” – See [¶0067] and Fig. 3); memory coupled with the processor; and instructions stored in the memory and executable by the processor (“storage 320 stores data such as a basic program, an application program, and configuration information for an operation of the terminal 120” and “provides stored data according to the request of the controller 330” – See [¶0071] and Fig. 3); to cause the apparatus to perform the steps of Amended Claim1 (“the controller 330 may control the terminal 120 to perform operations according to embodiments to be described,” e.g., in Regarding Amended Claim 1, supra – See [¶0072]). Because Amended Claim 1 is obvious over Kang in view of 3GPP R2-2100001 Report, Amended Claim 29 is also obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 30, dependent from Amended Claim 29, Kang further teaches wherein:
the service supported by the logical network associated with the physical network is a network slice ( the “network may provide one or multiple vertical slices and services . . . identified by slice/service type (SST) values of the corresponding slices/services” – See [¶0085] and Table 1, and “the identification information may be indicated by NSSAI of the corresponding network slice or may be composed of a slice ID mapped to the NSSAI of the corresponding network slice in addition to an identity (ID) of a slice group including the corresponding network slice” – See [¶0092]), and
the service-based random access procedure type is a slice-based random access procedure type (“the dedicated RRC signaling may provide slice specific RACH-Dedicated configuration information” which “may configure different RACH resources to one or multiple slices/service NSSAI” – See [¶0105], including a slice-based random access procedure type that is defined in the RACH-Dedicated configuration information, as explained in Regarding Claim 1, supra), and
the service-based random access procedure is a slice-based random access procedure (“in the case of configuring an initial BWP for each slice/service, the terminal may transmit a RACH preamble in an initial BWP corresponding to a slice/service of interest, and stand by to receive a random access response (RAR) message, which is a response thereto in the initial BWP corresponding to the slice/service” – See [¶0141], whereby the slice/service-based random access procedure wherein a RAN selects and AMF based on the NSSAI provided by the UE is further described in §16.3.4.2 of 3GPP TS 38.300 V16.4.0 (2020-12), “Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 16),” published January 6, 2021; at pages 120-121 – See e.g., Figure 16.3.4.2-1, id.).
Therefore, Claim 30 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Amended Claim 31, dependent from Claim 30, Kang further teaches wherein the instructions to receive the random access configuration are executable by the processor to cause the apparatus to:
receive an indication that the network slice is associated with the priority level (“Slice/service-based system access configuration information transmitted through the system broadcast message formed in FIGS. 6A and 6B uses the same RACH resource, but may be configured in a manner that applies different prioritization parameters for each slice/service” – See [¶0097], Fig. 6B, and “[i]n the case that one cell supports one or more slices/services, system access configuration information including a prioritization parameter to be applied to one or multiple slices/service NSSAI may be formed and provided to the terminal” – See [¶0099]; in addition, an “access category . . . configured to each slice/ service may, for example, use values of 32 to 63 reserved for use by the operator” and the “value for a slice/service configured by the service provider may be transmitted to the terminal” as prioritization parameter – See [¶0168] and Table 8)
wherein selection of the slice-based random access procedure type is based at least in part on the priority level of the network slice (“The terminal may perform a system access procedure using a RACH resource and/or prioritization parameter configured to a slice/service” – See [¶0099] and Table 4, wherein the powerRampingStepHighPriority parameter of the RA-Prioritization IE indicates a prioritized random access procedure indicating different levels for different slices/services – See [¶¶0097-98] wherein “rachConfigCommon information may include SupportedSliceinfo information and RA-Prioritization information corresponding thereto”; see also 3GPP TS 38.331:561; in addition, the RACH-ConfigDedicated for a slice may also contain ra-PrioritizationTwoStep instead of ra-Prioritization to indicate a prioritized 2-step random access type procedure – See 3GPP TS 38.331: 557; furthermore, for services using “an access category parameter of a system access control configuration,” – See [¶0167] and TABLE 8, at page 15, the terminal may “perform . . . service access procedure with reference to other configuration information (frequency, cell, priority) of the corresponding slice” – See [¶¶0175,0177], whereby the level of priority may be correlated with the access category number using Access Identity in decreasing order, as shown in TABLE 8, at page 15 and TABLE 2, at page 6-7, showing ra-PrioritizationForAccessidentity or ra-PrioritizationForAI in the RACH-ConfigCommon IE; see also 3GPP TS 38.331:550 (describing ra-PrioritizationForAI); i.e., the slice-based random access procedure type is based at least in part on the priority level of the network slice3 configured through RACH-ConfigDedicated of the slice and/or through RACH-ConfigCommon of the slice/service-based system; 3GPP R2-2009199 supra disclosing slice-specific ra-Prioritization based on UAC Access Categories).
Therefore, Claim 31 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 32, dependent from Claim 31, while Kang teaches the apparatus of claim 31, wherein the instructions to select the slice-based random access procedure type are further executable by the processor to cause the apparatus to:
determine the priority level specific to the slice (the terminal may “perform . . . service access procedure with reference to other configuration information (frequency, cell, priority) of the corresponding slice” – See [¶¶0175,0177]; whereby the level of priority may be correlated with the access category number using Access Identity in decreasing order, as shown in TABLE 8, at page 15, and “Slice/service-based system access configuration information transmitted” to the UE may use “the same RACH resource, but may be configured in a manner that applies different prioritization parameters for each slice/service” – See [¶0097], e.g., slices requiring faster access such as ultra-reliable low latency (URLLC) service shown in TABLE 1, at page 6, may use faster RACH access such as 2-step RA), Kang does not explicitly teach where the threshold priority to distinguish between 2-step and 4-step RA sits. However, it would be obvious for a person of ordinary skills in the art, appraised by Kang teaching that “A service provider may perform a function of configuring an access category value for a supporting slice/service,” to set a threshold value for distinguishing between high priority and low priority slices, e.g., on the lower end of “values of 32 to 63 reserved for use by the operator” – See [¶0168].
In addition, 3GPP R2-2009199 already teaches, at page 1, “[t]o provide RA prioritization to different slices or slice groups similar to MPS and MCS” for “some of the slices (e.g. URLLC)” based on the Access Identities and Access Categories listed in Table 6.22.2.2-1 and Table 6.22.2.3-1, 3GPP 22.261, at page 34-36, supra, reproduced in TABLE 8 of Kang, at page 15, indicating at least one type of slice, the URLLC, in the same high priority range as Emergency Services and Multimedia Services (Access Category 2 and 4-5). Therefore, a threshold priority value of 32 would sufficiently distinguish high priority slices/services from lower priority slices/services, i.e., all other MO access cases.
3GPP R2-2009974 further teaches to select a two-step slice-based random access procedure as the slice-based random access procedure type based at least in part on the priority level being greater than the threshold priority level, as explained in Amended Claim 1 and Amended Claim 29 supra, for high priority slices.
Therefore, Claim 32 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 33, dependent from Claim 31, Kang in view of 3GPP R2-2100001 Report teaches the apparatus of claim 31, wherein the instructions to select the slice-based random access procedure type are further executable by the processor to cause the apparatus to: determine the priority level among the Access Categories available to the operator, as explained supra. 3GPP R2-2009974 further teaches to select a two-step slice-based random access procedure as the slice-based random access procedure type only for those slices that are critical (“reduce[] the number of UEs allowed to select 2-Step RACH and allow[] UEs to use more power during MsgA_PUSCH to increase RA success probability”). Therefore, 3GPP R2-2009974 effectively teaches select a four-step slice-based random access procedure as the slice-based random access procedure type based at least in part on the priority level being less than the threshold priority level, as it was also explained in Regarding Amended Claim 29, supra.
Therefore, Claim 33 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Amended Claim 34, dependent from Claim 30, Kang in view of 3GPP R2-2100001 Report further teaches the apparatus of claim 30 wherein the instructions to receive the random access configuration are executable by the processor to cause the apparatus to:
receive an indication that the network slice is associated with the priority level (“In the case that one cell supports one or more slices/services, system access configuration information including a prioritization parameter to be applied to one or multiple slices/service NSSAI may be formed and provided to the terminal,” – See Kang:[¶0099] e.g., “An access category value for a slice/service configured by the service provider may be transmitted to the terminal” – See Kang:[¶0168] in a uac-BarringForSlice as shown in Fig. 11 of Kang and/or a slice specific configuration rach-ConfigCommonSliceX for access as shown in Fig. 6B of Kang)
and that the priority level is associated with the reference signal received power threshold (a new RA-Prioritization IE, the ra-PrioritizationForAC so that “RA prioritization (including powerRampingStepHighPriority and scalingFactorBI) for operator defined access categories can be introduced in system information to prioritize random access for certain slices implicitly” through RACH-ConfigCommonSliceX – See 3GPP R2-2009806, at page 1, referenced by 3GPP R2-2100001 Report, whereby RACH-ConfigCommonSliceX comprises both the ra-Prioritization and rsrp-ThresholdSSB for selection of RACH resources for access, as shown in TABLE 2 of Kang, at page 6-7; furthermore, “2-Step RACH was introduced in Release 16 with, among other goals, to allow UEs fast access to PUSCH resources” specifically the mechanism based on msgA-rsrp-Threshold described in 3GPP TS 38.321 supra, that “would effectively allow faster access to the intended slice for high priority slices. This solution also allows fine tuning of slices priorities and enables RACH isolation. Indeed, UEs not meeting its slice-defined RSRP threshold would fallback to 4-Step RACH,” whereby “slice-based RSRP thresholds [are used] for selection between 2-Step and 4-Step RACH” – See 3GPP R2-2009974, at page 2, referenced by 3GPP R2-2100001 Report) wherein selection of the slice-based random access procedure type is based at least in part on the priority level of the network slice and satisfaction of the reference signal received power threshold, as explained in Regarding Amended Claims 1 and 29, supra.
Therefore, Amended Claim 34 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Amended Claim 35, dependent from Amended Claim 34, Kang further teaches the apparatus of claim 34 wherein the instructions to select the slice-based random access procedure type are further executable by the processor to cause the apparatus to:
determine that the measured reference signal received power is greater than the reference signal received power threshold; and select a two-step slice-based random access procedure as the slice-based random access procedure type based at least in part on the measured reference signal received power being greater than the reference signal received power threshold (explained in Regarding Amended Claims 1 and 29, when msgA-RSRP-Threshold, “an RSRP threshold for selection between 2-step RA type and 4-step RA type when both 2-step and 4-step RA type Random Access Resources are configured” – See 3GPP TS 38.321 at page 16, is used as explained in Regarding Amended Claim 34 supra, “Signalling slice-specific msgA-rsrp-Threshold . . . would effectively allow faster access to the intended slice for high priority slices” by selecting 2-step RA procedure – See 3GPP R2-2009974, at page 2, referenced by 3GPP R2-2100001 Report, whereby “[t]he terminal may measure an RSRP value of a cell” and “determine[] that an RSRP measurement value is greater than or equal to the threshold” – See Kang:[¶0135] and Fig. 10).
Therefore, Amended Claim 35 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Amended Claim 36, dependent from Amended Claim 34, Kang further teaches the apparatus of claim 34 wherein the instructions to select the slice-based random access procedure type are further executable by the processor to cause the apparatus to:
determine that a measured reference signal received power is less than the reference signal received power threshold (“[t]he terminal may measure an RSRP value of a cell” and “determine[] that an RSRP measurement value is smaller than a threshold” – See [¶0135] and Fig. 10).
3GPP R2-2009974, referenced by 3GPP R2-2100001 Report further teaches, at page 2, select a four-step slice-based random access procedure as the slice-based random access procedure type based at least in part on the measured reference signal received power being less than the reference signal received power threshold (“UEs not meeting its slice-defined RSRP threshold would fallback to 4-Step RACH”).
Therefore, Amended Claim 36 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 37, dependent from Amended Claim 34, Kang in view of 3GPP R2-2100001 Report further teaches the apparatus of claim 34 wherein the priority level is greater than the threshold priority level because it would be obvious for a person of ordinary skills in the art, appraised by Kang teaching that “A service provider may perform a function of configuring an access category value for a supporting slice/service,” to set a threshold value for distinguishing between high priority and low priority slices, e.g., on the lower end of “values of 32 to 63 reserved for use by the operator” – See [¶0168]. Furthermore, 3GPP R2-2009199 referenced by 3GPP R2-2100001 Report, discloses at page 1 “To provide RA prioritization to different slices or slice groups similar to MPS and MCS” which are low Access Category/high priority slices, so that “some of the slices (e.g. URLLC) may benefit from this, particularly from the case of resumption to reduce control plane latency and also for fast access to the intended critical slices.” Therefore, the priority level is greater than the threshold priority level at least in the case of some slices.
Therefore, Claim 37 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 38, dependent from Claim 30, Kang further teaches the apparatus of claim 30 wherein the instructions to receive the random access configuration are executable by the processor to cause the apparatus to:
receive an indication of a first random access procedure threshold for attempting random access with the physical network using the slice-based random access procedure type (as shown in TABLE 2, at page 6-7, and Fig. 6B, the UE receives in RACH-ConfigCommonSliceX a first random access procedure threshold and other parameters specific to accessing slice/service in RACH-ConfigCommonSliceX configuration, e.g., a ra-ContentionResolutionTimer ; see also – See 3GPP TS 38.331, at page 550, defining a ra-ContentionResolutionTimer as “The initial value for the contention resolution timer (see TS 38.321 [3], clause 5.1.5)”; 3GPP TS 38.321, at page 34-36 explaining the role of ra-ContentionResolutionTimer).
Therefore, Claim 38 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 39, dependent from Claim 38, Kang further teaches the apparatus of claim 38, wherein the first random access procedure threshold is a duration of time, e.g., the ra-ContentionResolutionTimer, as explained in Regarding Claim 38, supra.
Therefore, Claim 39 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 40, dependent from Claim 38, Kang further teaches the apparatus of claim 38, wherein the first random access procedure threshold is a number of attempts (e.g., TABLE 2, at page 6-7, showing an example of RACH-ConfigCommonSliceX includes the slice specific RACH-ConfigDedicated wherein parameters such as preambleTransMax and ra-ResponseWindow are defined as “Max number of RA preamble transmission performed before declaring a failure (see TS 38.321 [3], clauses 5.1.4, 5.1.5)” and “(RAR) window length in number of slots” – See 3GPP TS 38.331, at page 559).
Therefore, Claim 40 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 41, dependent from Claim 38, Kang further teaches the apparatus of claim 38, wherein the instructions are further executable by the processor to cause the apparatus to:
attempt to perform the slice-based random access procedure until the first random access procedure threshold is satisfied (“if ra-ContentionResolutionTimer expires . . . consider the Contention Resolution not successful.” – See § 5.1.5, 3GPP TS 38.321, at page 35, cited by 3GPP TS 38.331, whereby “the terminal has acquired a rach-ConfigSpecificSlice associated with an identifier corresponding to a slice/service of interest thereof” – See Kang:[¶0103]); and
switch to a common4 random access procedure based at least in part on satisfaction of the first random access procedure threshold (“if the Contention Resolution is considered not successful . . . . if the Random Access procedure is not completed” and “the RA_TYPE is set to 2-stepRA” and “PREAMBLE_TRANSMISSION_COUNTER = msgA-TransMax + 1” then “set the RA_TYPE to 4-stepRA” – See id.; whereby it would be obvious to a person of ordinary skills in the art that 4-stepRA is the common access procedure that could be specified, e.g., in rach-ConfigCommon – See Kang:[¶0101]).
Therefore, Claim 41 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Amended Claim 42, dependent from Claim 41, Kang further teaches the apparatus of claim 41 wherein:
the UE switches to a two-step common random access procedure based at least in part on the slice-based random access procedure type being a two-step slice-based random access procedure (if “RA_TYPE is set to 2-stepRA” and “if msgA-TransMax is applied (see clause 5.1.1a) and PREAMBLE_TRANSMISSION_COUNTER [is less than] msgA-TransMax + 1” then “select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF” and “perform the Random Access Resource selection procedure for 2-step RA type as specified in clause 5.1.2a” – See § 5.1.5, 3GPP TS 38.321, at page 35-36, cited by 3GPP TS 38.331, whereby the 2-stepRA is the common access procedure that could be specified, e.g., in rach-ConfigCommonSlice – See Kang:[¶0101]), or
the UE switches to a four-step common random access procedure based at least in part on the slice-based random access procedure type being a four-step slice-based random access procedure (“if the RA_TYPE is set to 4-stepRA . . . select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF” and “perform the Random Access Resource selection procedure (see clause 5.1.2)”– See id., at page 35; whereby the 4-stepRA is the common access procedure that could be specified, e.g., in rach-ConfigCommonSlice – See Kang:[¶0101]).
Therefore, Amended Claim 42 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 44, dependent from Claim 38, Kang in view of 3GPP R2-2100001 Report further teaches the apparatus of claim 38, wherein the instructions to receive the random access configuration are executable by the processor to cause the apparatus to:
receive an indication of a second random access procedure threshold associated with a second slice-based random access procedure type (“Signalling slice-specific msgA-rsrp-Threshold and ΔMsgA_PUSCH would effectively allow faster access to the intended slice for high priority slices” – See 3GPP R2-2009974, at page 2, referenced by 3GPP R2-2100001 Report), the slice-based random access procedure type being a first slice-based random access procedure type different from the second slice-based random access procedure type (whereby msgA-rsrp-Threshold is configured for 2-step RA procedure – See 3GPP 38.331, at page 551-554, specifying the IE RACH-ConfigCommonTwoStepRA “used to specify cell specific 2-step random-access type parameters” that may be slice-specific as taught in Kang for the corresponding RACH-ConfigCommonSliceX).
Therefore, Claim 44 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 45, dependent from Claim 44, Kang in view of 3GPP R2-2100001 Report further teaches the apparatus of claim 44, wherein the instructions are further executable by the processor to cause the apparatus to:
attempt to perform random access with the physical network using the first slice-based random access procedure type until satisfaction of the first random access procedure threshold; switch to use of the second slice-based random access procedure type for random access based at least in part on satisfaction of the first random access procedure threshold without successful random access using the first slice-based random access procedure type; (“start the ra-ContentionResolutionTimer” and monitor for “notification of a reception of a PDCCH transmission of the SpCell is received from lower layers” to “consider this Contention Resolution successful;” otherwise, “if ra-ContentionResolutionTimer expires . . . consider the Contention Resolution not successful” and “if the Random Access procedure is not completed” and “the RA_TYPE is set to 2-stepRA” and “PREAMBLE_TRANSMISSION_COUNTER = msgA-TransMax + 1” then “set the RA_TYPE to 4-stepRA” – See § 5.1.5, 3GPP TS 38.321, at page 35, cited by 3GPP TS 38.331, whereby the 4-step RA is the second random access procedure type )
attempt to perform random access with the physical network using the second slice-based random access procedure type until satisfaction of the second random access procedure threshold (following the 3GPP TS 38.321 standard for the random access procedure configured through in rach-ConfigSpecificSlice – See Kang:[¶0102] and explained supra, “when both 2-step and 4-step RA type Random Access Resources are configured” the UE would perform 4-step RA as long as the measured RSRP – See Kang:[¶0123] is less than msgA-RSRP-Threshold , the “RSRP threshold for selection between 2-step RA type and 4-step RA” – See § 5.1.1, 3GPP TS 38.321, at page 16, referenced by 3GPP TS 38.321 and by 3GPP R2-2009974, at page 2, referenced by 3GPP R2-2100001 Report, for slice-specific msgA-RSRP-Threshold); and
switch to use of a four-step common random access procedure type for random access based at least in part on satisfaction of the second random access procedure threshold without successful random access using the second slice-based random access procedure type (“UEs not meeting its slice-defined RSRP threshold would fallback to 4-Step RACH” – See 3GPP R2-2009974, at page 2, referenced by 3GPP R2-2100001 Report),
wherein the first slice-based random access procedure type is a two-step slice-based random access procedure type and the second slice-based random access procedure type is a four-step slice-based random access procedure type, as explained supra.
Therefore, Claim 45 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 46, dependent from Claim 38, Kang in view of 3GPP R2-2100001 Report further teaches the apparatus of claim 38, wherein the instructions to receive the random access configuration are executable by the processor to cause the apparatus to:
receive an indication of a second random access procedure threshold associated with a second slice-based random access procedure type (e.g., the slide-specific msgA-RSRP-Threshold available in 2-step RA “rach-ConfigSpecificSlice including system access configuration information on the slice/service” – See Kang:[¶0102] and 3GPP R2-2009974, at page 2, referenced by 3GPP R2-2100001 Report)
and a third random access procedure threshold associated with a two-step common random access procedure type (e.g., the cell/PLMN-specific msgA-RSRP-Threshold available in rach-ConfigCommonTwoStepRA whereby “[t]he UE selects 2-step random access type to perform random access based on this threshold (see TS 38.321 [3], clause 5.1.1). This field is only present if both 2-step and 4-step RA type are configured” – See 3GPP 38.331, at page 553)
the slice-based random access procedure type being a first slice-based random access procedure type different from the second slice-based random access procedure type, for example the slice-based random access procedure type being a first slice-based random access procedure type 2-step RA and the second slice-based random access procedure type 4-step RA, as explained supra.
Therefore, Claim 46 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 47, dependent from Claim 46, the claim language merely repeats the limitations in Claim 45 disclosing a 2-step RA procedure fallback to a 4-step RA procedure for accessing, e.g., the slice/service configured for access through both 2-step and 4-step RA procedure types. This fallback procedure is described in 3GPP TS 38.321 at pages 35-36, referenced by 3GPP 38.331, as explained in Regarding 45, supra, using the same logic and threshold parameters whereby the UE firstly attempts slice-based RA procedures and then falls back to the common slice and/or cell procedure as described by 3GPP standards, only here the common RA procedure is a 2-step RA procedure to be tried before falling back to the 4-step RA procedure.
Therefore, Claim 47 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 48, dependent from Claim 38, Kang in view of 3GPP R2-2100001 Report further teaches the apparatus of claim 38, wherein the instructions to receive the random access configuration are executable by the processor to cause the apparatus to: receive an indication of a second random access procedure threshold associated with a two-step common random access procedure type (e.g., beside RACH-ConfigCommon, the UE is configured through broadcasted SI with cell/PLMN-specific msgA-RSRP-Threshold available in rach-ConfigCommonTwoStepRA whereby “[t]he UE selects 2-step random access type to perform random access based on this threshold (see TS 38.321 [3], clause 5.1.1). This field is only present if both 2-step and 4-step RA type are configured” – See 3GPP 38.331, at page 553).
Therefore, Claim 48 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 49, dependent from Claim 48, the claim language merely discloses attempt and finally failure of a 4-step RA procedure performed on a configured slice/service using an expiration threshold as first random access procedure threshold, as already explained in Regarding Claims 45 and 47, supra, followed by the two-step common random access procedure type with standard fallback to 4-step RA procedure. Because Claims 45 and 47-48 are obvious over Kang in view of 3GPP R2-2100001 Report, Claim 49 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 50, dependent from Claim 30, Kang further teaches wherein the instructions are further executable by the processor to cause the apparatus to: identify a second network slice to be accessed by the UE via a second slice-based random access procedure (“the InitialUplinkBWP information may include at least one or a combination of rach-ConfigCommonSliceA information, rachConfigCommonSliceB information to rachConfigCommonSliceN information indicating system access configuration information of terminals interested in a slice/service A, a slice/service B, or a slice/service N . . . configured independently of the rachConfigCommon information of Table 2” – See [¶0090] and TABLE 2 at page 6-7, and Fig. 6B)
wherein the slice-based random access procedure is a first slice-based random access procedure that is different from the second slice-based random access procedure (“system access configuration information of terminals interested in a slice/service A, a slice/service B, or a slice/service N” are “configured independently” – See id., e.g., one may be a critical slice hence configured with fast access through 2-step RA – See, e.g., 3GPP R2-2009974, at page 2, referenced by 3GPP R2-2100001 Report), and
the network slice is a first network slice that is different from the second network slice – See [¶0090] and Fig. 6B.
Therefore, Claim 50 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 51, dependent from Claim 50, Kang in view of 3GPP R2-2100001 Report further teaches the apparatus of claim 50, wherein the instructions are further executable by the processor to cause the apparatus to:
receive an indication that the first network slice is associated with a first priority level and the second network slice is associated with a second priority level (high priority/critical slices based on Unified Access Control – See Kang:[¶0149] and Fig. 11, as explained in Regarding Claim 34 supra, was proposed in RAN2 WG as a separate prioritization parameter ra-PrioritizationForAC, e.g., in RACH-ConfigCommonSliceX so that “RA prioritization (including powerRampingStepHighPriority and scalingFactorBI) for operator defined access categories can be introduced in system information to prioritize random access for certain slices implicitly”– See 3GPP R2-2009806, at page 1, referenced by 3GPP R2-2100001 Report).
Therefore, Claim 51 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 55, dependent from Amended Claim 29, Kang further teaches the apparatus of claim 29, wherein the instructions to receive the random access configuration are further executable by the processor to cause the apparatus to:
receive at least a portion of the random access configuration in a system information block message (“system access configuration information of the terminal may be transmitted while being included in a system broadcast message SIB1,” including “rach-ConfigCommon information” – See [¶0088] and Figs. 6A and 6B).
Therefore, Claim 55 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 56, dependent from Amended Claim 29, Kang further teaches the apparatus of claim 29, wherein the instructions to receive the random access configuration are further executable by the processor to cause the apparatus to:
receive at least a portion of the random access configuration in a radio resource control message ((“[t]he slice/service-based system access configuration information may be provided to a terminal in a radio resource control (RRC) connection state through dedicated RRC signaling, wherein the dedicated RRC signaling may provide slice specific RACH-Dedicated configuration information”– See [¶0105]). Furthermore, § 5.1.1 of 3GPP TS 38.321, at page 16, referenced by 3GPP TS 38.331 in relationship with RACH-ConfigCommon, discloses a list of RA procedure parameters configured by RRC).
Therefore, Claim 56 is obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Amended Claim 58, Kang teaches a non-transitory computer-readable medium storing code for wireless communications at a user equipment (UE), the code comprising instructions executable by a processor (“The storage 320 stores data such as a basic program, an application program, and configuration information for an operation of the terminal 120. The storage 320 may be composed of a volatile memory, a non-volatile memory, or a combination of a volatile memory and a non-volatile memory. The storage 320 provides stored data according to the request of the controller 330” – See [¶0071] and Fig. 1, whereby “the controller 330 may control the terminal 120 to perform operations according to embodiments to be described” – See [¶0072]) to perform the method described in Amended Claim 1. Because Amended Claim 1 is obvious over Kang in view of 3GPP R2-2100001 Report, Amended Claim 58 is also obvious over Kang in view of 3GPP R2-2100001 Report.
Regarding Claim 115, Kang in view of 3GPP R2-2100001 Report further teaches the apparatus of claim 29, wherein: the priority level comprises a first priority level [[or]]and a second priority level different from the first priority level – See, e.g., 3GPP R2-2009199 at page 1, referenced by 3GPP R2-2100001 Report, stating that “it is thus true that some of the slices (e.g. URLLC) may benefit from” prioritization, i.e., some slices have a first priority level and some have a higher priority level, e.g. using Access Categories as further taught in Kang:[¶0168] and 3GPP R2-2009806, at page 1, referenced by 3GPP R2-2100001 Report. Because Kang specifically teaches a slice-specific RACH-ConfigCommonSliceX – See [¶0093], or group of slices specific rach-ConfigCommonSlice – See [¶0090] and Figs. 6A and 6B, hence comprising a slice-specific or group of slices specific rsrp-ThresholdSSB threshold, respectively – See TABLE 2 at page 6-7, Kang in view of 3GPP R2-2100001 Report effectively teaches a first reference signal received power threshold is dedicated to the first priority level, e.g., high priority slice(s) and a second reference signal received power threshold different from the first reference signal received power threshold is dedicated to the second priority level, e.g. low priority slice(s).
Therefore, Claim 115 is obvious over Kang in view of 3GPP R2-2100001 Report.
In sum, Claims 1, 29-42, 44-51 and 55-56, 58, and 115 as amended, are rejected under 35 U.S.C. 103 as obvious over Kang in view of 3GPP R2-2100001 Report (and 3GPP references included therein).
Claim(s) 52-54 are rejected under 35 U.S.C. 103 as being unpatentable over Kang in view of 3GPP R2-2100001 Report as applied to claim51 above, and further in view of of Nuggehalli et al., U.S. Patent Application No. 2023/0300739 (hereinafter Nuggehalli).
Regarding Claim 52, dependent from Claim 51, Kang in view of 3GPP R2-2100001 Report teaches the apparatus of claim 51 wherein the instructions are further executable by the processor to cause the apparatus to: determine that the first network slice is of higher priority than the second network slice, e.g., based on the Access Category, as explained in both Kang:[¶0168] and 3GPP R2-2009806, at page 1, referenced by 3GPP R2-2100001 Report.
Although the standard teaches concurrent RA procedures – See, e.g., § 5.1.1, 3GPP TS 38.321, at page 16 (“NOTE 1: If a new Random Access procedure is triggered while another is already ongoing in the MAC entity, it is up to UE implementation whether to continue with the ongoing procedure or start with the new procedure (e.g. for SI request)”), Kang in view of 3GPP R2-2100001 Report does not teach suspend the second slice-based random access procedure based at least in part on the first network slice having higher priority than the second network slice.
Nuggehalli teaches method and apparatus whereby, just like in Kang in view of 3GPP R2-2100001 Report, “the base station may provide a number of dedicated, slice-specific RACH configurations to the UE (e.g., in a SIB or dedicated RRC message), such that the UE can identify and use the appropriate RACH configuration when requesting network support information for a given slice” – See [¶0005].
Nuggehalli further teaches a priority level of the network slice (“the UE 102 can transmit its list of desired slices (possibly with priority values) to a serving base station” – See [¶0041] and Fig. 1, whereby “the NAS controller 144 may inform the AS controller 142 of the priority level for [each] network slice” whereby “slice-specific priority level that was configured by the network (e.g., by base station 104A)” or “the priority level may be pre-defined (e.g., by the OEM)” – See [¶0048]) and that the priority level is greater than a threshold priority level (“the slice support query unit 146” at the UE determines that “the overlap of desired slices and supported slices [must] satisfy particular criteria,” e.g., “all desired slices that have at least a threshold priority level” – See [¶0040] and Fig. 1), including determining that the first network slice is of higher priority than the second network slice (“the UE 102 determines 814 that data associated with a first network slice is ready for transmission, and determines 816 that data associated with a different, second network slice is also ready for transmission . . . at the same time” – See [¶0092] and Fig. 8, and “decides to attempt channel access for the data associated with the first network slice before attempting channel access for the data associated with the second network slice” based on “the first network slice (or its associated data) having a higher priority than the second” – See [¶0093]); and
suspend the second slice-based random access procedure based at least in part on the first network slice having higher priority than the second network slice (“the UE 102 is ready to transmit uplink data associated with two different slices at the same time (or at overlapping times, etc.), and in which the base station 104A supports (or may support) both of those slices. In these cases, the UE 102 may need to prioritize its attempts to gain channel access for the data associated with the different slices” – See [¶0085], i.e., the lower priority RA attempt is suspended until the first is completed or fails as a way to prioritize attempts to gain channel access for the data associated with the different slices; furthermore, a person of ordinary skills in the art would know that “[t]here is only one Random Access procedure ongoing at any point in time in a MAC entity” – See 3GPP TS.38.321, at page 16).
Thus, Kang in view of 3GPP R2-2100001 Report and Nuggehalli each discloses a UE configured with network slice associated priority and dedicated RACH configuration information performing selection of the slice-based random access procedure type whereby the UE determines that the first network slice is of higher priority than the second network slice. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the step of suspending the second slice-based random access procedure based at least in part on the first network slice having higher priority than the second network slice as taught in Nuggehalli, could have been combined with the step of selecting a service-based random access procedure type based at least in part on the random access configuration and the priority of the service/slice to be accessed by the UE, as taught in Kang in view of 3GPP R2-2100001 Report, because both references provide for differential PRACH configuration for multiple services/slices types. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination through techniques known in the art. Finally, the combination achieves the predictable result of allowing faster access and data transmission to the UE for a higher priority slice, as taught by both Kang in view of 3GPP R2-2100001 Report and Nuggehalli.
Therefore, Claim 52 is obvious over Kang in view of 3GPP R2-2100001 Report, and further in view of Nuggehalli.
Regarding Claim 53, dependent from Claim 51, Kang in view of 3GPP R2-2100001 Report further teaches the apparatus of claim 51, wherein the instructions are further executable by the processor to cause the apparatus to: determine that the second network slice is of higher priority than the first network slice, as explained supra.
Nuggehalli further teaches wherein the instructions are further executable by the processor to cause the apparatus to:
abort the first slice-based random access procedure based at least in part on the second network slice having higher priority than the first network slice; and perform the second slice-based random access procedure in place of the first slice based random access procedure (when “the UE 102 determines that the second network slice and/or its associated data has a higher priority than the first network slice and/or its associated data . . . the UE 102 then terminates the first RACH procedure and instead starts a second RACH procedure to attempt channel access for the second network slice data” – See [¶0095]).
Therefore, Claim 53 is obvious over Kang in view of 3GPP R2-2100001 Report, and further in view of Nuggehalli.
Regarding Claim 54, dependent from Claim 50, Kang in view of 3GPP R2-2100001 Report further teaches the apparatus of claim 50, wherein the instructions are further executable by the processor to cause the apparatus to: suspend the second slice-based random access procedure based at least in part on the first slice-based random access procedure already being in progress – See, e.g., § 5.1.1, 3GPP TS 38.321, at page 16 (“NOTE 1: If a new Random Access procedure is triggered while another is already ongoing in the MAC entity, it is up to UE implementation whether to continue with the ongoing procedure or start with the new procedure (e.g. for SI request),” e.g,, the UE may suspend the second RA procedure).
Nuggehalli also and more specifically teaches a scenario at the UE wherein the instructions are further executable by the processor to cause the apparatus to: suspend the second slice-based random access procedure based at least in part on the first slice-based random access procedure already being in progress (“the UE 102 determines 814 that data associated with a first network slice is ready for transmission, and determines 816 that data associated with a different, second network slice is also ready for transmission” whereby “event 816 may occur after the first RACH procedure has started (e.g., after event 862 but before event 882” – See [¶0092] and Fig. 8; in this case, the second slice-based random access procedure is still suspended, as further explained in [¶0093-94]).
Therefore, Claim 54 is obvious over Kang in view of 3GPP R2-2100001 Report, and further in view of Nuggehalli.
In sum, Claims 52-54 are rejected under 35 U.S.C. 103 as obvious over Kang in view of 3GPP R2-2100001 Report and further in view of Nuggehalli.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Li et al., U.S. Patent Application No. 2023/0199859 as applied in previous Office Actions;
Murray et al., U.S. Patent Application No. 2020/0252976 discloses RA procedures in general and configuration parameters for a slice-specific physical random access channel (PRACH) resource on the network;
Murray et al., U.S. Patent Application No. 2022/0272760 discloses method and apparatus for 2-step RA procedure;
Seidel et al., U.S. Patent Application Publication No. 2023/0092324 discloses method and apparatus for random access with slice specific RACH resource configuration;
Gao et al., U.S. Patent Application Publication No. 2023/0029004 discloses technical details of network slices and network slice configuration including RACH configurations and procedures;
Li, U.S. Patent Application Publication No. 2022/0353908 discloses method and apparatus for fined-grained control at a slice level performed based on access control information, backoff information, a timer, and other information related to the slice;
3GPP TSG-RAN WG2 Meeting #112 Electronic, R2-2009423, Title: “RACH prioritisation for slices,” Source: Nokia, Nokia Shanghai Bell, November 2020;
3GPP TSG-RAN WG2 Meeting #112 Electronic, R2-2009806, Title: “Consideration on the slice specific RACH configuration,” Source: ZTE Corporation, Sanechips, published November 2020;
3GPP TSG-RAN WG2 Meeting #112 Electronic, R2-2009199, Title: “Consideration of slice based RACH,” Source: Intel Corporation, published November 2020;
3GPP TSG-RAN WG2 Meeting #112 Electronic, R2-2010232, Title: “2-step RACH and 4-step RACH selection criteria for SDT,” Source: Xiaomi, published November 2020;
3GPP TSG-RAN WG2 Meeting #112 Electronic, R2-2009974, Title:” RACH enhancements to enable UE fast access to the intended slice,” Source: NEC, published November 2020;
3GPP TSG-RAN WG2 Meeting #112 Electronic, R2-2011062, 38.331 CR 2149, Title: “Corrections to 2-Step RA,” Source: Ericsson, Huawei, published November 2020;
3GPP TSG-RAN WG2 Meeting #112 Electronic, R2-2009969, 38.321 CR 0953, Title: “Parameter corrections to 2-Step RA,” Source: Ericsson, published October 2020;
3GPP TS 38.331 V16.3.1 (2021-01), “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 16),” published January 6, 2021;
3GPP TS 22.261 V17.5.0 (2020-12) Technical Specification Group Services and System Aspects; Service requirements for the 5G system; Stage 1 (Release 17)”;
3GPP TS 38.321 V16.3.0 (2020-12), “Technical Specification Group Radio Access Network; NR; Medium Access Control (MAC) protocol specification (Release 16)”;
3GPP TS 23.501 V16.7.0 (2020-12), “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16)”, published January 6, 2021;
3GPP TS 38.300 V16.4.0 (2020-12), “Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 16),” published January 6, 2021;
3GPP TS 28.530 V17.0.0 (2020-12), “Technical Specification Group Services and System Aspects; Management and orchestration; Concepts, use cases and requirements (Release 17),” published December 2020
3GPP TS 28.531 V16.8.0 (2020-12), “Technical Specification Group Services and System Aspects; Management and orchestration; Provisioning; (Release 16),” published January 7, 2021.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LUCIA GHEORGHE GRADINARIU whose telephone number is (571)272-1377. The examiner can normally be reached Monday-Friday 9:00am - 5:00pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Joseph AVELLINO can be reached at (571)272-3905. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/L.G.G./ Examiner, Art Unit 2478
/JOSEPH E AVELLINO/ Supervisory Patent Examiner, Art Unit 2478
1 A person of ordinary skills in the art would know that 3GPP TS 28.530 V17.0.0 (2020-12), “Technical Specification Group Services and System Aspects; Management and orchestration; Concepts, use cases and requirements (Release 17),” published December 2020 (hereinafter 3GPP TS 28.530), describes, at page 5-6, “[n]etwork slicing” as “a paradigm where logical networks/partitions are created, with appropriate isolation, resources and optimized topology to serve a purpose or service category (e.g. use case/traffic category, or for MNO internal reasons) or customers (logical system created ‘on demand’. It further defines “network slice” as “a logical network that provides specific network capabilities and network characteristics, supporting various service properties for network slice customers”, and at page 11 describes the relationship between a Network Slice and Network Functions to deliver communication services in Figure 4.1.6.1.
2 A person of ordinary skills in the art would recognize that § 5.12.2.1 of 3GPP TS 23.501:196-198 describes a standalone NSSAI (S-NSSAI) as identifying a network slice, and being comprised of SST, and optionally a SD, like in Table 5, at page 9 of Kang, whereby “[t]he NSSAI is a collection of S-NSSAIs. An NSSAI may be a Configured NSSAI, a Requested NSSAI or an Allowed NSSAI. There can be at most eight S-NSSAIs in Allowed and Requested NSSAIs sent in signalling messages between the UE and the Network. The Requested NSSAI signalled by the UE to the network allows the network to select the Serving AMF, Network Slice(s) and Network Slice instance(s) for this UE, as specified in clause 5.15.5,” and “[t]he details of how the RAN uses NSSAI information are described in TS 38.300,” referencing 3GPP TS 38.300 V16.4.0 (2020-12), “Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 16),” published January 6, 2021 (hereinafter 3GPP TS 38.300)).
3 3GPP TS 38.321 was amended to provide prioritized RACH procedure for UEs configured for Multimedia Priority Service (MPS) and/or Mission Critical Service (MCS) (access identity 1 and 2) using also ra-Prioritization (containing the fields powerRampingStepHighPriority and scalingFactorBI) further described in § 5.1.1, 3GPP 38.321:21-22, in addition to the case when ra-Prioritization is configured in the rach-ConfigDedicated, as disclosed in Kang for slice/service prioritization parameters. The purpose of using ra-Prioritization is “to provide lower latency and higher probability of success to the RACH procedure particularly during times of network overload when otherwise would not be possible with regular RACH parameters” – See 3GPP TSG-RAN2 Meeting #109 Electronic, R2- 2002103 (38.321, CR 0675), March 2020 (hereinafter 3GPP R2-2002103).
4 The term “common random access procedure” is not specifically defined in the Specification but rather meant to be understood by contrast with “slice-based random access procedure” – See, e.g., Spec [¶0047]. Kang distinguishes between RA procedures using slice-specific RACH parameters and using slice-common RACH parameters – See, e.g., [¶¶0102-03](“rach-ConfigCommonSlice and rach-ConfigSpecificSlice including system access configuration information on a slice/service may be defined”; “If it is determined that the terminal has acquired a rach-ConfigSpecificSlice associated with an identifier corresponding to a slice/service of interest thereof” and “If it is determined that the terminal has not acquired a rach-ConfigSpecificSlice associated with an identifier corresponding to a slice/service of interest thereof, the terminal may perform a system access procedure using system access configuration information indicated in the rach-ConfigCommonSlice”); and further between slice-based RACH procedure and common, i.e., non-slice based, as provided by the standards at the time of filing the present Application – See [¶0101] (“If it is determined that the terminal has not acquired a rachConfigCommonSlice corresponding to a PLMN identifier thereof, but corresponding to a slice/service identifier of interest, the terminal may perform a system access procedure using system access configuration information indicated in the rach-ConfigCommon”). It is understood by one of ordinary skills in the art that a UE configured with each of these rach-Config would first access the intended slice – See [¶0104](“system access configuration information indicated in a rach-ConfigSpecificSlice may be used in the case that the terminal supporting the associated PLMN performs a system access procedure in order to receive a slice/service corresponding to the associated slice/service identification information”) but “the terminal may determine to perform a system access procedure using general system access configuration information, that is, a RACH-ConfigCommon” – See [¶0115].
Prosecution Insights