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 .
Response to Amendment
The amendment to the claims filed on 04/07/2026 complies with the requirements of 37 CFR 1.121(c) and has been entered. Claims 1, 3, 8 and 15 are amended.
Response to Arguments
Applicant’s arguments with respect to the independent claims 1, 8 and 15 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for the matter specifically challenged in the argument, i.e., “a respective priority for each of the respective service types based on the network data and the service data.”
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.
Claims 1-20, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Schliwa-Bertling et al., U.S. Patent Application Publication No. 2020/0336885 (hereinafter Schliwa-Bertling) in view of Ohlsson et al., U.S. Patent Application Publication No. 2022/0174464, (hereinafter Ohlsson) and further in view of 3GPP TS 22.011 V18.4.0 (2022-12), “Technical Specification Group Services and System Aspects; Service accessibility (Release 18)” (hereinafter 3GPP TS 22.011).
Regarding Amended Claim 1, Schliwa-Bertling teaches a method, comprising:
receiving, by a network device and from a plurality of core networks (“The network node may be an AMF in SGC, an NG RAN of a SGS (e.g., gNB or eNB connected to SGC), or a non-3GPP WLAN AP connected to SGC. The network node may also be an IMS node connected to SGC, such as for example a CSCF node” – See [¶0143]; in addition, “3GPP decided that a NR and E-UTRA/LTE can provide access to 5GC” and that “a cell providing access using E-UTRA can provide access via EPC as well as 5GC” meaning “that such cell can be serving UEs connected to either core networks and thus provide the respective services,” i.e., can receive information from multiple core networks – See [¶0004])
network data identifying the plurality of core networks supported by the network device and emergency service data identifying one or more of the plurality of core networks that support emergency services (the “multi-access wireless device . . . to access emergency services” – See [¶0007], “controlling access of a wireless device for Emergency Services” that “comprises the step of determining for the wireless device at least one of one or more other core network or system . . . is able to support ES and is in the same Public Land Mobile Network, PLMN, as the first core network or system or in one or more other PLMN,” i.e., network data –See [¶0012] whereby “the ES information . . . should [also] indicate fallback to an EPS, i.e., indicates that the UE uses a different base station in the 3GPP access network,” i.e., emergency services data, and “the indication that EPC be used corresponds to an indication of using EPC based NAS,” i.e., the indication is received from the core network – See [¶0070])
generating, by the network device and based on the network data and the emergency service data, system information that includes a cell identifier for the network device, a tracking area code associated with the network device, and identifiers of the plurality of core networks and indicators of whether the plurality of core networks support emergency services (as taught in prior art, the E-UTRA/LTE base station “may broadcast support for Internet Multimedia Subsystem, IMS, emergency call in SysteminformationBlockTypel (SIB1) sent over the radio interface” as “shown in bold/underlined in the ASN of SIB Type 1 of Table 1 below as specified in 3GPP TS 36.331” – See [¶0005], indicating1 cell access information comprising: plmn-IdentityList–each PLMN indicating a pair Mobile Country Code/Mobile Network Code (MCC/MNC) allocated to a public operator; trackingAreaCode; cellldentity, and ims-EmergencySupport-r9 ENUMERATED {true} “indicat[ing] if the E-UTRAN/EPC system (EPS) support emergency call support using limited service mode” – See [¶0006]);
wherein an indicator for each core network of the plurality of core networks supported by the network device indicates whether each core network supports emergency services (“To mitigate the delay to access to Emergency services in a multi-system environment, i.e., an environment that supports multiple accesses and multiple core networks . . . the 5GC/5GS provides the . . . wireless device . . . with information indicating . . . that different core network or system or cell (i.e., radio access node), such as EPC/EPS or eNB respectively in the same PLMN or other PLMN supports ES” – See [¶0055], whereby “the information is obtained [by a UE] from a broadcast signaling over a broadcast channel or from a dedicated signaling” – See [¶0121] and Fig. 4, so that “[i]f there is no EPC/EPS that supports ES, the UE can fallback to another network that supports ES such as 2G, 3G network” whereby “the information about the frequencies of other RATs (e.g. 2G CS, 3G CS) that are candidate to provide ES based on the information provided in the 5G system information” – See [¶¶0072-74]);
receiving, by the network device, service data identifying respective service types provided by each core network of the plurality of core networks (“in response to receiving . . . a request for a service that requires emergency handling, e.g., a request for voice service” – See [¶0145] “the network node provides . . . the UE or wireless device with information on whether another network/system such as LTE/EPC (i.e., EPS) for the same PLMN or other PLMN supports . . . access the service” – See [¶0146] i.e., the network device must know the service types provided by each core network of the plurality of core networks because the “Network Entity may be an AMF, gNB, eNB or IMS entity, depending on who is providing the ES information to the wireless device” – See [¶0153] and indicates the service type to the UE e.g., “provided on RRC level e.g., at initial RRC connection setup” – See [¶0067] or “it is provided over 5G on NAS level e.g. during 5G NAS registration” – See [¶0064]; see also 3GPP TS 38.300 infra specifying operator controlled Unified Access Control to core network services)
providing, by the network device to a user equipment, a list identifying a respective
priority for each of the respective service types based on the network data and the service datasending to the wireless device a message comprising ES information indicating that ES is provided by the at least one of the one or more other core network or system or the one or more radio access node capable of connecting to one or more other core network” – See [¶0012], e.g., “the UE receives an indication from the network indicating that basic service mode is supported via Non-Access Stratum, NAS, message comprising Emergency Service support indication and Voice over IMS, VoIMS support indication,” i.e., service types based on the network data and the service data; and “[i]f the UE has received ES information indicating more than one network/systems supporting ES than 5GS within the same PLMN or different PLMNs, the UE may use the priority provided in the ES information to select the other network/system to fallback to for sending the emergency request” – See [¶0141] whereby “the ES information may provide one or more other networks/systems that support ES and may provide an order of priority that the UE may use to select the network or system in the event of Emergency” – See [¶0137] whereby “[t]he information about the Core network/system that supports ES is provided to the UE while the UE is connected to 5GC to avoid the need for the UE to look and connect to yet another Core network/system or cell that does not support ES, when it needs to send an Emergency request,” i.e., the UE receives a list comprising the priority for ES based on network data and the ES service data – See [¶0057])
providing, by the network device, the system information to a user equipment to inform the user equipment about which of the plurality of core networks support emergency services, (“the information is obtained from a broadcast signaling over a broadcast channel or from a dedicated signaling” whereby “system herein refers to a core network in combination with the supported access network(s)” – See [¶0121] and “Broadcast signaling over a broadcast channel may comprise: System information broadcasted from” the access device – See [¶¶0122-23]); and
receiving, from the user equipment, an emergency call directed to a core network of the plurality of core networks, the core network selected by the user equipment based on the respective priorityreceiving a request indicating emergency from a UE or receiving a request for a service that requires emergency handling, e.g., a request for voice service” – See [¶0145] whereby “the UE may use the priority provided in the ES information to select the other network/system to fallback to for sending the emergency request” – See [¶0141]).
While Schliwa-Bertling discloses that ES capability information is provided per core network/PLMN, Schliwa-Bertling does not disclose a specific bit/mask/format for the broadcasted as system information, e.g., SysteminformationBlockType1, to associate the ES information with each core network/PLMN. However, Ohlsson, which like Schliwa-Bertling, teaches “methods, systems, and apparatuses for indicating to and/or directing a wireless device to a network that supports emergency services” – See [¶0014], and further teaches, also like Schliwa-Bertling, that network node uses system information to convey ES core network capability (the “network node . . . is configured to indicate . . . , in a System Information Block, SIB, whether a network supports an Internet Protocol, IP, Multimedia Subsystem, IMS, emergency communication service, the indication associated to a network identifier, the network identifier identifying the network” – See [¶0100]), specifically acknowledges the limitation of the SIB1 signaling in prior art when it comes to multiple core networks sharing the same radio access2 – See [¶0146] (“in SIB1 the information indicating whether emergency is supported, ‘ims-EmergencySupport’ parameter, is not indicated per network/Cell Identity (ID); in other words, the same indication is used for all networks/cell IDs sharing the same physical cell”).
Ohlsson, further teaches SIB enhancement to support per core network ES information for assisting a UE with requesting emergency services – See [¶0145](“the System Information, SIB, could separate the ‘ims-EmergencySupport’ per PLMN (per network identity/identifier) and the wireless device 22, via processing circuitry 84, can decide network identity, e.g., PLMN . . . based on the indicated support,” i.e., “a per-network emergency support indication may be provided (e.g., sent by network node 16 to WD 22) via the ‘ims-EmergencySupport’ SIB parameter”)(emphasis added).
Thus, Schliwa-Bertling and Ohlsson each teaches a method in a wireless communication system with one or more core networks available for a UE to access through a network access device and providing support for emergency services, whereby the indication is broadcasted for the UE in a system information block/message. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the enhanced SIB containing per-network ES support indication using ‘ims-EmergencySupport’ per PLMN (per network identity/identifier), as taught in Ohlsson, could have been combined with the step of generating system information that includes identifiers of the one or more core networks supporting ES, as taught by Schliwa-Bertling, because both methods rely on broadcasted system information, e.g., SIB1/ SysteminformationBlockType1, comprising a list of PLMNs and emergency services availability, to send such indication to the UE. 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 reducing the delay to access to Emergency services in multiple core networks, as taught by Schliwa-Bertling while reusing an existing system information format enhanced for multiple core network support, as taught by Ohlsson – See [¶0055].
Schliwa-Bertling:[¶0212] further references 3GPP TS 23.401 V17.7.0 (2022-12), “Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 17)” (hereinafter 3GPP TS 23.401) regarding service types supported by each core network – See [¶0042] (“the UE receives an indication from the network indicating that basic service mode is supported via Non-Access Stratum, NAS, message comprising Emergency Service support indication and Voice over IMS, VoIMS support indication. further described in 3GPP TS 23.401” and “3GPP TS 23.167” for IMS services3).
3GPP TS 23.401 discloses, at page 108, an Allocation and Retention Priority (ARP) for IMS roaming scenarios (“apply the same allocation and retention priority for IMS voice service for all users (i.e. roamers and non-roamers) and to apply the same allocation and retention priority for all MPS service users . . . when roaming agreements are in place and where regulatory requirements apply”) distinguishing per service type priority (e.g., the “Multimedia Priority Service (MPS),” described at page 73-74, which “supports priority sessions on an ‘end-to-end’ priority basis” whereby “MPS subscription allows users to receive priority services, if the network supports MPS,” and “includes indication for support of Priority EPS Bearer Service, IMS priority service and CS Fallback priority service support for the end user” while “[t]he terminating network identifies the priority of the MPS session and applies priority treatment, including paging with priority, to ensure that the MPS session can be established with priority to the terminating user,” i.e., a user whose “MPS subscription entitles [its] USIM with special Access Class(es)”). 3GPP TS 23.401 further specifies, at page 67, that “preferential access to the network is provided to the UE by the Access Class 11-15 mechanism,” i.e., special Access Classes. Although 3GPP TS 23.401, referenced by Schliwa-Bertling, specifies services types provided with priority in certain networks/PLMNs that support such high priority access, 3GPP TS 23.401 only references, for the various emergency or priority IMS supported services, 3GPP TS 22.101 V18.4.0 (2022-06), “Technical Specification Group Services and System Aspects; Service aspects; Service principles” (hereinafter 3GPP TS 22.101) wherein, at page 52, it is specified that for such services, the “Network selection procedures are defined in 3GPP TS 22.011” and at page 11, that 3GPP TS 22.261 specifies “Service requirements for the 5G system; Stage 1.”
Therefore, Schliwa-Bertling in view of Ohlsson does not teach: (1) a list identifying a respective priority for each of the respective service types based on the network data and the service data; and (2) the core network selected by the user equipment based on the respective priority of a service type provided by the core network
3GPP TS 22.011 specifies at page 10, in § 3.2, network selection procedures for various service types, indicating that “[i]t shall be possible to have an Operator Controlled PLMN Selector list and a User Controlled PLMN Selector list stored on the SIM/USIM card. Both PLMN Selector lists may contain a list of preferred PLMNs in priority order,” e.g., a priority based on the network/PLMN data and service data, whereby the priority of service type is established as follows:
Section 4, at page 18, specifies Access Class based access control, whereby if “the Access Class is applicable in the serving network, access attempts are allowed” and “[t]he network operator can take the network load into account when allowing UEs access to the network,” further indicating the network domain of application for each special Access Class, e.g., whether only Home PLMN or Home and Visited PLMN; for example, in case of extraneous network conditions, special Access Class 11-15 are allocated to specific high priority Service Users such as Emergency Services users in “Home and Visited PLMNs of home country only.” Furthermore, “[i]n the case of multiple core networks sharing the same access network, the access network shall be able to apply Access Class Barring for the different core networks individually,” therefore the RAN receives data identifying respective service types provided by each core network.
Note 1: 3GPP TR 22.950 V17.0.0 (2022-03), “Technical Specification Group Services and System Aspects; Priority Service feasibility study (Release 17)” (hereinafter 3GPP TR 22.950) discloses in §6, at page 13, that Service Accessibility, which is standardized in 3GPP TS 22.011, “supports an Access Control capability that is pertinent to Priority Service” and lists, in Table 1, reproduced below, the Access Classes in order of priority, based on the type of Service users, i.e., the service data, and the domain of applicability, i.e., the network data.
Table 1: Service Accessibility Access Classes
Access Class
Usage
Applicability
15
PLMN Staff
Home PLMN Only
14
Emergency Services
Home and Visited PLMNs
of home country only
13
Public Utilities
12
Security Services
11
For PLMN Use
Home PLMN Only
0 - 9
General Use
Home and Visited PLMNs
Note 2: 3GPP TS 22.261, referenced by 3GPP TS 22.101, specifies in § 6.7, at page 26, that “the 5G system should allow a flexible means to prioritise and enforce prioritisation among the services (e.g. MPS, Emergency, medical, Public Safety) and among the users of these services,” and in § 6.19, at page 37-38, the network selection for Slices/Service Types (SSTs), whereby a “5G network operator controls and is responsible for what SSTs that should be available to a specific UE and subscription combination” and “can populate the Operator Controlled PLMN Selector list . . . with the PLMN/RAT combinations enabling access to the SSTs that are available to the 5G UE,” further specifying, in § 6.22, at page 39 “a single unified access control where operators control accesses based on . . . Access Identities and Access Categories” that also “allow[s] operators to define operator-defined Access Categories using their own criterion (e.g. network slicing, application, and application server),” as shown in Table 6.22.2.3-1, at page 41, reproduced below
Table 6.22.2.3-1: Access Categories
Access Category number
Conditions related to UE
Type of access attempt [i.e., service type]
0
All
MO signalling resulting from paging
1 (NOTE 1)
UE is configured for delay tolerant service and subject to access control for Access Category 1, which is judged based on relation of UE’s HPLMN and the selected PLMN.
All except for Emergency, or MO exception data
2
All
Emergency
3
All except for the conditions in Access Category 1.
MO signalling on NAS level resulting from other than paging
4
All except for the conditions in Access Category 1.
MMTEL voice (NOTE 3)
5
All except for the conditions in Access Category 1.
MMTEL video
6
All except for the conditions in Access Category 1.
SMS
7
All except for the conditions in Access Category 1.
MO data that do not belong to any other Access Categories (NOTE 4)
8
All except for the conditions in Access Category 1
MO signalling on RRC level resulting from other than paging
9
All except for the conditions in Access Category 1
MO IMS registration related signalling (NOTE 5)
10 (NOTE 6)
All
MO exception data
11-31
Reserved standardized Access Categories
32-63 (NOTE 2)
All
Based on operator classification
NOTE 1: The barring parameter for Access Category 1 is accompanied with information that define whether Access Category applies to UEs within one of the following categories:a) UEs that are configured for delay tolerant service;b) UEs that are configured for delay tolerant service and are neither in their HPLMN nor in a PLMN that is equivalent to it;c) UEs that are configured for delay tolerant service and are neither in the PLMN listed as most preferred PLMN of the country where the UE is roaming in the operator-defined PLMN selector list on the SIM/USIM, nor in their HPLMN nor in a PLMN that is equivalent to their HPLMN.When a UE is configured for EAB, the UE is also configured for delay tolerant service. In case a UE is configured both for EAB and for EAB override, when upper layer indicates to override Access Category 1, then Access Category 1 is not applicable.
NOTE 2: When there are an Access Category based on operator classification and a standardized Access Category to both of which an access attempt can be categorized, and the standardized Access Category is neither 0 nor 2, the UE applies the Access Category based on operator classification. When there are an Access Category based on operator classification and a standardized Access Category to both of which an access attempt can be categorized, and the standardized Access Category is 0 or 2, the UE applies the standardized Access Category.
NOTE 3: Includes Real-Time Text (RTT).
NOTE 4: Includes IMS Messaging.
NOTE 5: Includes IMS registration related signalling, e.g. IMS initial registration, re-registration, and subscription refresh.
NOTE 6: Applies to access of a NB-IoT-capable UEto a NB-IOT cell connected to 5GC when the UE is authorized to send exception data.
effectively teaching a list identifying a respective priority for each of the respective service types that an Operator may apply to any UE request for the respective service type based on the network data and the service data4.
3GPP TS 22.011 further specifies, at page 19, an algorithm/logic used by UEs to anticipate whether a request for a service type of a certain Access Category will be barred or not, therefore effectively teaching the core network selected by the user equipment based on the respective priority of a service type5 provided by the core network because each “serving network shall be able to broadcast mean durations of access control and barring rates (e.g. percentage value) that commonly applied to Access Classes 0-9 to the UE.” Finally, 3GPP TS 22.011 recommends that special Access Classes are allocated to emergency calls and MPS elevating them to higher priority classes, e.g., “one of the special access classes 11 to 15” for MPS, so that they are barred only when these special classes are not allowed, i.e., they get the highest priority – See id., at page 24.
Thus, Schliwa-Bertling in view of Ohlsson and 3GPP TS 22.011 each teaches multiple service types provided by multiple core networks, 5G or EPC, sharing the same RAN. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the UE prioritisation of a core network selection based on the respective priority of a service type provided by the core network, whereby a list identifying a respective priority for each of the respective service types based on the network data and the service data could be the operator controlled list of Access Categories to service types, including ES, as taught in 3GPP TS 22.011, could enhance the step of selecting a core network for emergency services (ES) as taught in Schliwa-Bertling in view of Ohlsson because both rely on 3GPP standard specifications for managing priority access to CN system resources in situations such as during congestion and enhanced SIB broadcast by the shared RAN to inform UEs of their chances to access priority services with each core network providing them. 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 a UE to predictably select a core network based on the respective priority of a service type provided by the core network as taught by the algorithms disclosed in 3GPP TS 22.011.
Therefore, Amended Claim 1 is obvious over Schliwa-Bertling in view of Ohlsson, further in view of 3GPP TS 22.011.
Regarding Claim 2, dependent from Amended Claim 1, Schliwa-Bertling in view of Ohlsson further teaches the method of claim 1, further comprising:
receiving, from the user equipment, an emergency call directed to one of the plurality of core networks that supports emergency services, as selected by the user equipment based on the identifiers and the indicators included in the system information (“the UE performs the step of determining the network to connect to for an emergency request based on the received ES information from the 5GC/SGS” – See Schliwa-Bertling:[¶0139] and Figs. 2 and 4 whereby the ES information is obtained from “System information broadcasted from the gNB system information broadcast channel” – see [¶0123]; furthermore, “the network node executes the step 500 of determining for a UE connected to a 5GC/5GS that one or more other core networks/ systems other than the 5GC or 5GS should provide Emergency services for the UE . . . in response to receiving a request indicating emergency from a UE or receiving a request for a service that requires emergency handling, e.g., a request for voice service” – See Schliwa-Bertling:[¶0145] and Fig. 5)
directing the emergency call to the one of the plurality of core networks that supports emergency services (“If the UE has received ES information indicating more than one network/systems supporting ES than 5GS within the same PLMN or different PLMNs, the UE may use the priority provided in the ES information to select the other network/system to fallback to for sending the emergency request” – See Schliwa-Bertling:[¶0141], and “may be required to suspend or release the connection to 5GC prior to sending the emergency request to the other network that supports ES” – See Schliwa-Bertling:[¶0140]).
Ohlsson further describes the scenario wherein the UE is camped on the 5GS and makes an Emergency Service Request to an EPC supporting ES, as shown in Fig. 16 – See [¶0136] whereby, “some embodiments may provide for the NG-RAN (e.g., network node 16a) to trigger a handover or redirection still within NR but to a different PLMN by e.g., indicating the target CN PLMN ID” received from the UE – See [¶0137].
Therefore, Claim 2 is obvious over Schliwa-Bertling in view of Ohlsson, and further in view of 3GPP TS 22.011.
Regarding Amended Claim 3, dependent from Amended Claim 1, Schliwa-Bertling in view of Ohlsson further teaches the method of claim 1 further comprising:
generating, based on the network data and the service data, the list identifying the plurality of core networks and priorities associated with service types provided by the plurality of core networks (“the ES information may provide one or more other networks/systems that support ES and may provide an order of priority that the UE may use to select the network or system in the event of Emergency. The priority may be provided on the basis of PLMNs associated to the network/system or based on the technology type. For instance, LTE/EPC has priority over 2G, 3G systems”– See Schliwa-Bertling:[¶0137]) wherein
the priorities associated with service types provided by the plurality of core networks correspond, e.g., to the Access Categories Table 6.22.2.3-1 supra, including operator-defined Access Categories using their own criteria.
3GPP TS 22.011, at page 19, further teaches that the shared RAN generates the list (“serving network shall be able to broadcast” Access Class information6 and “the access network shall be able to apply Access Class Barring for the different core networks individually”).
Therefore, Amended Claim 3 is obvious over Schliwa-Bertling in view of Ohlsson, further in view of 3GPP TS 22.011.
Regarding Claim 4, dependent from Amended Claim 3, Schliwa-Bertling in view of Ohlsson further teaches the method of claim 3, further comprising:
receiving, from the user equipment, a request for a first service type, directed to one of the plurality of core networks that supports the first service type, as selected by the user equipment based on the list wherein the one of the plurality of core networks is associated with a greatest priority for the first service type relative to the plurality of core networks other than the one of the plurality of core networks (“the UE performs the step of determining the network to connect to for an emergency request based on the received ES information from the 5GC/5GS” – See [¶0139], whereby “[i]f the UE has received ES information indicating more than one network/systems supporting ES than 5GS within the same PLMN or different PLMNs, the UE may use the priority provided in the ES information to select the other network/system to fallback to for sending the emergency request” – See Schliwa-Bertling:[¶0141], the “UE [is] connected to a 5GC/5GS that one or more other core networks/ systems other than the 5GC or 5GS should provide Emergency services for the UE” and the “request [is] for a service that requires emergency handling, e.g., a request for voice service” – See Schliwa-Bertling:[¶0145] and the priority is per service type as required for 5GS – See § 6.7, 3GPP TS 22.261:26-27); and
directing the request for the first service type to the one of the plurality of core networks that supports the first service type (“require[ing the UE] to suspend or release the connection to 5GC prior to sending the emergency request to the other network that supports ES” – See [¶0140], and/or using “fallback [service] to for sending the emergency request” – See Schliwa-Bertling:[¶0141]).
Therefore, Claim 4 is obvious over Schliwa-Bertling in view of Ohlsson, and further in view of 3GPP TS 22.011.
Regarding Claim 5, dependent from Claim 4, Schliwa-Bertling in view of Ohlsson further teaches the method of claim 4, further comprising:
receiving, from the user equipment, a request for a second service type directed to another one of the plurality of core networks that supports the second service type as selected by the user equipment based on the list (“the UE receives an indication from the network indicating that basic service mode is supported,” in a “message comprising Emergency Service support indication and Voice over IMS, VoIMS support indication” as “further described in 3GPP TS 23.401 (clauses 4.3.5.8 and 4.3.12) and 3GPP TS 23.167” – See Schliwa-Bertling:[¶0042], i.e., emergency services and VoIMS emergency services are two service types7)
wherein the other one of the plurality of core networks is associated with a greatest priority for the second service type relative to the plurality of core networks other than the other one of the plurality of core networks (“The priority may be provided on the basis of PLMNs associated to the network/system or based on the technology type. For instance, LTE/EPC has priority over 2G, 3G systems” – See Schliwa-Bertling:[¶0137]; hence LTE/EPC will be the first priority for the second service type)
directing the request for the second service type to the other one of the plurality of core networks that supports the second service type (“the NG-RAN is able to trigger handover or redirection from NR to E-UTRA connected to 5GC at QoS Flow establishment for IMS Emergency Services (e.g. voice)” – See 3GPP TS 23.501:257; see also Schliwa-Bertling:[¶0057] (when VoIMS/eCall over IMS is not “supported by 5GC/5GS, the latter suggests or instructs the UE that it should connect to other core network/system/cell such as EPC/EPS/cell represented by for example an eNB, in order to receive” the service)).
Therefore, Claim 5 is obvious over Schliwa-Bertling in view of Ohlsson, and further in view of 3GPP TS 22.011.
Regarding Claim 6, dependent from Amended Claim 1, Schliwa-Bertling in view of Ohlsson teaches that SysteminformationBlockTypel (SIB1) is used to broadcast support for ES by one or more other core networks, including per-network ES indication information, wherein Ohlsson teaches a specific format for SIB 1 to convey such indication, as explained in Regarding Amended Claim 1 supra. Because 3GPP TS 38.331: 412-413 already defines the type for the ims-EmergencySupport parameter in SIB1 as an enumerated Boolean (“ENUMERATED {true}”), it is inherent that a 1 bit per network, e.g., per each PLMN in the plmn-IdentityList field, would suffice for supporting the indication8).
Therefore, Claim 6 is obvious over Schliwa-Bertling in view of Ohlsson, and further in view of 3GPP TS 22.011.
Regarding Claim 7, dependent from Amended Claim 1, Ohlsson further teaches the method of claim 1, wherein the user equipment is connected to a private network supported by the network device (“the indication of whether the network supports the IMS emergency communication service is associated to . . . a combination of the PLMN ID and the NID [that] identifies a standalone non public network, SNPN, to which the indication of whether the network supports the IMS emergency communication service is associated to.” – See [¶0017] and Fig. 1, or a “non-public network, NPN” – See [¶0019]; see also 3GPP TS 38.331:411 disclosing SIB1 parameter cellAccessRelatedInfo further containing imsEmergencySupportForSNPN indicators, each associated with the corresponding SNPN identity– See id.:518).
Therefore, Claim 7 is obvious over Schliwa-Bertling in view of Ohlsson, and further in view of 3GPP TS 22.011.
Regarding Amended Claim 8, Schliwa-Bertling in view of Ohlsson teaches a network device, comprising: one or more processors (e.g., in Fig. 2, “[i]f NG-RAN is an LTE eNB it may be able to connect to network 106, 5GC, and/or to Network 106b, such as an Evolved Packet Core, EPC” – See Schliwa-Bertling:[¶0077] and/or “may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 160, such as, for example, LTE, NR, WiFi wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 160” – See Schliwa-Bertling:[¶0084] wherein “processing circuitry 170 can be configured to perform the described functionality. The benefits provided by such functionality are not limited to processing circuitry 170 alone or to other components of network node 160 but are enjoyed by network node 160 as a whole, and/or by end users and the wireless network generally” – See [¶0087]) configured to execute the combined steps of Claims 1 and 2, as amended, recited with the same language. Because each of Claims 1 and 2, as amended, are obvious over Schliwa-Bertling in view of Ohlsson, and further in view of 3GPP TS 22.011, Amended Claim 8 is obvious over Schliwa-Bertling in view of Ohlsson, and further in view of 3GPP TS 22.011.
Regarding Claims 9 and 10, each dependent from Amended Claim 8, each merely recite the steps of Claims 6 and 7, respectively, with no other limitations. Because each of Claims 6-8, as amended, is obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011, Claims 9 and 10 are also obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011.
Regarding Claims 11 and 12, each dependent from Amended Claim 8, Schliwa-Bertling in view of Ohlsson discloses multiple core networks of different generations:
Schliwa-Bertling teaches the network device wherein the plurality of core networks are fifth-generation standalone core networks (“a 5GS herein comprises a 5GC and a 5G RAN as accessed by the UE” – See [¶00056] and that “at least one of one or more other core network or system . . . belong[s] to one or more other PLMN” and “is able to support ES” – See [¶0009]). Ohlsson discloses NG-RAN Enhancements “to use the Establishment cause or Resume cause "emergency" as to decide to select a NAS Node (5GC) supporting IMS Emergency,” i.e., a fifth-generation standalone core network – See [¶0148].
Schliwa-Bertling further teaches the network device wherein the plurality of core networks are fourth-generation evolved packet core networks (“one or more other core network or system, such as 4G EPC or EPS” – See [¶0009] even though the UE may receive the ES indication from a NG-RAN connected to a 5GC – See [¶0056]).
Furthermore, the indication of ES support through the broadcasted SIB1 information is associated with each PLMN ID in the plmn-IdentityList, therefore agnostic to the type of core network of each PLMN in the list, and 3GPP TS 22.011 further teaches, at page 9, that “selection of a core network operator among those connected to the shared radio access network can either be manual (i.e. performed by the user after obtaining a list of available core network operators) or automatic (i.e. performed by the UE according to user and operator preferred settings).”
Therefore, Claims 11-12 are obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011.
Regarding Claim 13, dependent from Amended Claim 8, Schliwa-Bertling in view of Ohlsson further teaches the network device of claim 8, wherein the network device is a radio access network device – See, e.g., Schliwa-Bertling:[¶0119] (“FIG. 4 illustrates a method performed by a UE connected or connecting to a first network, such as 5GC using NG-RAN which may be gNB or eNB”)
Therefore, Claim 13 is obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011.
Regarding Claim 14, dependent from Amended Claim 8, Schliwa-Bertling in view of Ohlsson further teaches the network device of claim 8, wherein a quantity of the plurality of core networks is greater than or equal to two (“to obtain fast access to Emergency Services requiring fallback from 5G system to another system, e.g. EPS, or 2G or 3G because ES is not supported by the 5G system” – See Schliwa-Bertling:[¶0075], e.g., “[i]f there is no EPC/EPS that supports ES, the UE can fallback to another network that supports ES such as 2G, 3G network” – See Schliwa-Bertling:[¶0072]), and at least one of the plurality of core networks supports emergency services (“at least one of one or more other core network . . . is able to support ES” – See Schliwa-Bertling:[¶0009], e.g., “ES information indicate that 5GC does not support ES and indicate support of ES by the other network” – See Schliwa-Bertling:[¶0130]).
Therefore, Claim 14 is obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011.
Regarding Amended Claim 15, Schliwa-Bertling in view of Ohlsson teaches a non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a network device (“Device readable medium 180 may comprise any form of volatile or non-volatile computer readable memory” and “may store any suitable instructions, data or information, including a computer program, software, an application including one or more of logic, rules, code, tables, etc. and/or other instructions capable of being executed by processing circuitry 170 and, utilized by network node 160” – See Schliwa-Bertling:[¶0088] and Figure 2), cause the network device to: execute the steps disclosed in Amended Claim 1. Because Amended Claim 1 is obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011, Amended Claim 15 is also obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011.
Regarding Claims 16 and 17, dependent from Amended Claim 15, taken together they merely recite the steps of Claim 4 performed by the device in Amended Claim 15, with no other limitations. Because Claims 4 and 15, as amended, are obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011, each of Claims 16 and 17 is obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011.
Regarding Claim 18, dependent from Claim 16, it merely describes the first two steps of Claim 5 performed by the device in Claim 16, with no other limitations. Because each of the Claims 5 and 16 is obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011, Claim 18 is obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011.
Regarding Claim 19, dependent from Claim 18, it merely recites the steps of the method performed in Claim 5 only executed by the device in Claim 18, with no other limitations. Because each of the Claims 5 and 18 is obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011, Claim 19 is obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011.
Regarding Claim 20, dependent from Amended Claim 15, the claim language merely recites the steps of the method in Claim 2, dependent from Amended Claim 1, performed together and in combination by the device in Amended Claim 15. Because each of Claims 2 and 15, as amended, is obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011, Claim 20 is also obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011.
In sum, Claims 1-20, as amended, are rejected under 35 U.S.C. §103 as obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 22.011.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Tang et al., U.S. Patent Application Publication No. 20220141636 as presented in previous office actions;
Ianev et al., U.S. Patent Application Publication No. 2024/0323828 as presented in previous office actions;
Devaki et al., U.S. Patent Application Publication No. 20190053028 discloses a UE and indication for controlling whether the user equipment makes an emergency call over a fifth-generation radio access technology or over another radio access technology as a fallback; and making, by the user equipment, the emergency call based on the received indication;
Bakker, U.S. Patent Application Publication No. 2021/0112394, disclosing emergency services handling with the UE in dual registration with a first core network and a second core network;
Arshad et al., U.S. Patent Application Publication No. 2020/0120470 discloses method allowing the wireless device to have immediate access to emergency services and no delaying emergency fallback procedure is performed;
Jin et al., U.S. Patent Application Publication No. 20240251330, disclosing a method for selecting another cell or PLMN when a disaster condition occurs and controlling an access in the selected another cell or PLMN in a mobile communication system;
Shih et al., U.S. Patent Application Publication No. 2022/0361098 discloses method of selecting an acceptable cell in an SNPN based on the SNPN support of IMS emergency service;
Kadiri et al., U.S. Patent Application Publication No. 2019/0021048 discloses methods, systems, and devices for wireless communication that provide for identification, on a per-PLMN basis of a type of core network associated with each PLMN in a list of networks associated with a base station;
Yanxia, CN Patent Application Publication No. 115134797 discloses method and apparatus for routing a first emergency service request to a core network function network element corresponding to a second type of network;
Weiwei et al., WIPO Patent Application Publication No. WO2020035000 discloses a method for obtaining a method for obtaining network configuration information for policy control based on analytics of each slice network list sent by the data analysis network element;
3GPP TS 22.011 V18.4.0 (2022-12), “Technical Specification Group Services and System Aspects; Service accessibility (Release 18)”;
3GPP TS 22.101 V18.4.0 (2022-06), “Technical Specification Group Services and System Aspects; Service aspects; Service principles”;
3GPP TS 23.401 V17.7.0 (2022-12), “Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 17)”;
3GPP TS 36.331 V17.3.0 (2022-12), “Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (Release 17)”;
3GPP TS 38.331 V17.3.0 (2022-12), “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 17)”;
3GPP TS 23.501 V18.0.0 (2022-12), “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 18),” December 2022;
3GPP TS 23.502 V18.0.0 (2022-12), “Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 18),” December 2022;
3GPP TS 23.167 V17.2.0 (2021-09), “Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS) emergency sessions (Release 17)”;
3GPP TS 23.251 V17.0.0 (2022-03), “Technical Specification Group Services and System Aspects; Network Sharing; Architecture and functional description (Release 17)”;
3GPP TS 32.130 V17.5.0 (2022-12), “Technical Specification Group Services and System Aspects; Telecommunication management; Network sharing; Concepts and requirements (Release 17),” December 2022;
3GPP TS 24.501 V18.1.0 (2022-12), “Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3; (Release 18),” December 2022;
3GPP TS 22.261 V18.8.0 (2022-12), “Technical Specification Group Services and System Aspects; Service requirements for the 5G system; Stage 1 (Release 18),” December 2022;
3GPP TS 38.300 V17.3.0 (2022-12), “Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 17)”.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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 See also the NR SIB 1 description in 3GPP TS 38.331 V17.3.0 (2022-12), “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 17)” (hereinafter 3GPP TS 38.331), at page 410-415, indicating ims-EmergencySupport and eCallOverIMS-Support in NR; equivalent to the referenced SysteminformationBlockType1 (SIB1) in E-UTRA/LTE and described in 3GPP TS 36.331 V17.3.0 (2022-12), “Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (Release 17)”, at page 448-458.
2 Multi-Operator Core Networks (MOCNs) are described in 3GPP TS 23.251 V17.0.0 (2022-03), “Technical Specification Group Services and System Aspects; Network Sharing; Architecture and functional description (Release 17)” (hereinafter 3GPP TS) whereby “a shared RAN is configured to indicate available core network operators for selection by UEs, each cell in shared radio access network shall in the broadcast system information include information concerning available core network operators in the shared network” and “the Broadcast System Information broadcasts a basic set of PLMN IDs and optionally one or more additional set of PLMN IDs . . . (see TS 36.331 [11])” – See 3GPP TS 23.251:9-10 and “[a] supporting UE decodes the broadcast system information to determine available core network operators in the shared network” and “[t]he core network operators together with all conventional networks are candidate PLMNs for the PLMN selection procedure that shall be performed by the UE as specified in TS 23.122 [4]” – See id. and Figure 2, showing a Multi-Operator Core Network (MOCN) in which multiple CN nodes are connected to the same RNC and the CN nodes are operated by different operators. In general, PLMN handling for network sharing is discussed for both public and private networks in § 5.8 of 3GPP TS 23.501 V17.7.0 (2022-12), “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 17),” (hereinafter 3GPP TS 23.501), noting that the broadcast system information for network sharing “is specified in TS 38.331 [28] for NR, TS 36.331 [51] for E-UTRA and related UE access stratum idle mode procedures in TS 38.304 [50] for NR and TS 36.304 [52] for E-UTRA”– See 3GPP TS 23.501:280; and that “[t]he cell connected to EPC and 5GC broadcasts separate broadcast indicator for EPC and 5GC to indicate support of emergency services by the EPC and 5GC” – See id.:257.
3 3GPP TS 23.167 V17.2.0 (2021-09), “Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS) emergency sessions (Release 17)” (hereinafter 3GPP TS 23.167) indicates, at page 8 that “the Access Network aspects that are crucial for the provisioning of IMS emergency services” rely on other 3GPP specifications, e.g., “TS 38.300 [50] contains an overall description of the Next Generation Radio Access Network (NG-RAN)”; NG-RAN/gNB are described in 3GPP TS 38.300 V17.3.0 (2022-12), “Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 17)” (hereinafter 3GPP TS 38.300), e.g., at page 20, the Overall Architecture, and at page 64-65, “identities are used in NG-RAN for identifying a specific network entity.” 3GPP TS 38.300 further specifies, at page 61, that: “One unified access control framework as specified in TS 22.261 [19] applies to all UE states . . . for NR. NG-RAN broadcasts barring control information associated with Access Categories and Access Identities (in case of network sharing, the barring control information can be set individually for each PLMN)” and “[t]he gNB handles access attempts with establishment causes "emergency", "mps-PriorityAccess" and "mcs-PriorityAccess" (i.e. Emergency calls, MPS, MCS subscribers) with high priority.”
4 Table 6.22.2.3-1 of 3GPP TS 22.261 includes Access Categories for services referenced in Schliwa-Bertling in view of Ohlsson, e.g., Emergency services and IMS voice services, and also includes the standardized Access Classes 11-15, wherein “the UE applies the Access Category based on operator classification” or “a standardized Access Category”; and each “serving PLMN should be able to provide the definition of operator-defined Access Categories to the UE” – See id., at page 40.
5 See, e.g., Service Specific Access Control (SSAC), described at page 22-23, whereby each EPS/core network “shall provide a capability to assign a service probability factor [13] and mean duration of access control for each of MMTEL voice and MMTEL video” and “shall be able to broadcast mean durations of access control, barring rates for Access Classes 0-9, barring status for Access class in the range 11-15 to the UE” so that “[t]he UE determines the barring status with the information provided from the serving network, and perform the access attempt accordingly.” Furthermore, “Application specific Congestion control for Data Communication (ACDC) is an access control mechanism for the operator to allow/prevent new access attempts from particular, operator-identified applications in the UE” whereby “Applications whose use is expected to be restricted the least shall be assigned the highest ACDC category; and - Applications whose use is expected to be restricted more than applications in the highest category shall be assigned the second-to-highest ACDC category, and so on,” i.e., a priority rank may be assigned to each Application or Service Type.
6 In Rel-18, SIB1 contains “configuration information that is common for all UEs and barring information applied to the unified access control” whereby “PLMN/SNPN specific configuration [is] provided in uac-BarringPerPLMN-List. The parameters are specified by providing an index to the set of configurations (uac-BarringInfoSetList)” – See 3GPP TS 38.331:414; furthermore, “[e]ach access category can be configured with access parameters” per each access identity, for each PLMN – See id.:915-916, wherein Unified Access Control is defined in § 4.5 of 3GPP TS 24.501 V18.1.0 (2022-12), “Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3; (Release 18)” (hereinafter 3GPP TS 24.501) defining the Access Identities a UE could use when accessing a service in Table 4.5.2.1, at page 69, and the Access Categories that a PLMN may support in Table 4.5.2.2, at page 71-74, e.g., Access Category 2 is for emergency session while categories 32-63 are based on operator classification which the UE learns/stores and “definitions are valid in the PLMN which provided them and in a PLMN equivalent to the PLMN which provided them, or in the SNPN which provided them and in an SNPN equivalent to the SNPN which provided them, as specified in annex C” – See id.:81; Section 4.5 3GPP TS 24.501:67 indicates that the “set of access identities and access categories [are] defined in 3GPP TS 22.261.”
7 See also SIB1 description in 3GPP TS 38.331: 410-415 wherein both ims-EmergencySupport and eCallOverIMS-Support are indicated to the UE with respective enumerated Boolean type indicating support per PLMN, whereby the first service type, ims-EmergencySupport, “[i]ndicates whether the cell supports IMS emergency bearer services for UEs in limited service mode” and the second service type, eCallOverIMS-Support, “[i]ndicates whether the cell supports eCall over IMS services as defined in TS 23.501”, whereby 3GPP TS 23.501:257-258 teaches that in shared RAN, a “cell connected to EPC and 5GC broadcasts separate broadcast indicator for EPC and 5GC to indicate support of emergency services by the EPC and 5GC,” and, similarly “[w]hen an E-UTRA cell is connected to EPC and 5GC, the cell broadcasts separate Access stratum broadcast indication for 5GC and EPC to indicate support of eCall over IMS by 5GC and EPC”; therefore, support for the first and the second service type is per core network, hence the UE in limited service mode with the 5GC can receive Emergency Services because in limited service state does not require a valid subscription; however, “[e]mergency calls for eCall Over IMS may only be performed if the UE has a USIM” – See id.:257, and, on the other hand, “[f]or an Emergency Registered UE over a given Access Type: the UE shall not initiate the UE Requested PDU Session Establishment procedure for normal service over this Access Type” and “the UE may attempt to receive normal service over another Access Type” – See id.:260-261, therefore, the UE would direct a eCall over IMS request to the EPC based on the USIM.
8 It is noted that a similar logic applies to the eCallOverIMS-Support parameter that is also of type enumerated Boolean – See 3GPP TS 38.331:413.
Prosecution Insights