CN114902641A

CN114902641A - 用于用户设备中的字符显示的方法和系统

Info

Publication number: CN114902641A
Application number: CN202080074384.5A
Authority: CN
Inventors: C·J-F·阿泽利耶
Original assignee: BlackBerry Ltd
Current assignee: BlackBerry Ltd
Priority date: 2019-10-24
Filing date: 2020-10-12
Publication date: 2022-08-12
Also published as: US20220377168A1; WO2021078549A1; EP4049440A1

Abstract

一种在用户设备处的方法，该方法包括在用户设备处接收标识标记字符串，字符串还包括指示符位；基于指示符位，执行以下中的一项：确定用户设备是否支持标记字符串中的一个或多个标记并且跳过与不支持的标记相对应的字符的显示；或显示标记字符串内的所有标记。在其他一些实施例中，利用语言轮廓符来选择要显示的标记字符串或向网络元件提供语言轮廓符并且基于所提供的语言轮廓符来使用从网络元件接收到的完整的标记字符串。

Description

用于用户设备中的字符显示的方法和系统

技术领域

本公开涉及在用户设备(UE)上显示字符，并且在一个实施例中涉及显示与用户设备连接到的网络有关的字符。

背景技术

用户设备通常向用户显示与用户所驻留的小区相对应的网络运营商的名称，也称为“运营方”。如果用户希望拨打电话或使用数据，这允许用户知道它将使用的运营方的名称。

具体地，当UE连接到公共陆地移动网络(PLMN)时，PLMN通常向UE提供网络名称信息。UE然后通常在显示屏上显示UE驻留的网络的名称。这可能处于空闲模式或连接模式。可以将网络名称信息提供给UE的一种方式被称为网络身份和时区(NITZ)特征，网络经由针对网络名称的文本字符串编码来发送该特征。可以根据全球移动通信系统(GSM)默认字母表或根据国际标准化组织/国际电工委员会(ISO/IEC)标准10646来执行编码，该标准指定了通用字符集(UCS)。

当在一个国家使用第一语言的用户漫游到使用另一种语言的另一个国家时，可能会出现问题。本地/受访PLMN可以在消息中向设备提供网络名称以供UE显示。然而，如果用户在设备上设置的语言与受访PLMN的语言不同，那么电话可能会以用户无法理解的语言向用户显示网络名称，或者可能会尝试显示与该UE上不支持的某些字符相对应的网络名称。

附图说明

参考附图将更好地理解本公开，其中：

图1是能够与本文描述的实施例一起使用的示例网络架构的框图；

图2是示出了网络信令的数据流图，该网络信令包括额外位以提供用于字符跳过的指示；

图3是示出了具有用于提供用于字符跳过的指示的附加位的示例消息的框图；

图4是示出了包括提供具有语言指示符的多个信令字段的网络信令的数据流程图；

图5是图4的消息的信令字段的框图，提供信令字段以及用于每个信令字段的语言指示符；

图6是示出了具有带有语言鉴别符的多个信令字段的示例信息元素的框图；

图7是示出了网络元件和用户设备之间的信令的数据流程图，其中用户设备向网络元件提供语言指示；

图8是示出了当网络元件知道用户设备的人机接口(MMI)的语言时所使用的示例信息元件的框图；

图9是能够与本公开的实施例一起使用的示例用户设备的框图；和

图10是能够与本公开的实施例一起使用的简化网络元件的框图。

具体实施方式

本公开提供了一种在用户设备处的方法，该方法包括在用户设备处接收标识的标记字符串，该字符串还包括指示位；基于指示位，执行以下之一：确定用户设备是否支持标记字符串中的一个或多个标记并且跳过与不支持的标记相对应的字符的显示；或显示标记字符串中的所有标记。在其他一些实施例中，利用语言轮廓符来选择要显示的标记字符串或向网络元件提供语言轮廓符并且基于所提供的语言轮廓符来使用从网络元件接收到的完整的标记字符串。

如本文中所使用的，术语“用户设备”或“UE”可以意指何移动设备、移动台并且可以指代移动设备，诸如任何移动电话、个人数字助理、手持或膝上型计算机以及具有电信能力的类似设备，所有这些都可以互换使用。这样的UE可以由设备及其关联的可移动存储器模块组成，诸如但不限于包括订户身份模块(SIM)应用、通用用户身份模块(USIM)应用或可移动用户身份模块(R-UIM)应用的通用集成电路卡(UICC)。替代地，这种UE可以由没有这种模块的设备本身组成。

如上面所提供的，UE可能需要向用户显示诸如网络名称之类的字符。根据第三代合作伙伴计划(3GPP)技术规范(TS)22.101，“服务方面；服务原则”，v.17.0.0，2019年9月，提供三种网络名称显示特征。这三个显示特征，从最高到最低优先级，是：

a.与PLMN身份相关联的设备的USIM中存储的PLMN名称，包括运营方的移动国家代码(MCC)和移动网络代码(MNC)；

b.经由NITZ特征在来自网络的信令中接收到的PLMN名称；和

c.存储在移动设备(ME)中并与运营方的PLMN身份相关联的PLMN名称。

以此方式，无线网络或无线电接入网络可以使用多个方案之一向连接的UE提供网络信息。网络信息可以被显示在UE上以向该UE的用户提供关于网络的信息，诸如网络名称、国家名称、表示网络的图形和/或其他相关信息。

鉴于在3GPP TS 22.101标准中提供的三个选项，如果UE支持多于一种用于显示网络信息的特征，则UE可以使用具有最高优先级的特征而忽略剩余的特征。通常，USIM信息具有最高优先级，并且因此可以首先尝试从USIM获取信息。

来自NITZ的信息具有第二高优先级，并且如果USIM信息不可用，则UE可以尝试使用该信息。

ME信息具有第三优先级，并且因此如果其他两个特征都不可用或不被支持，则UE可以尝试使用该信息。

在一些情况下，例如在使用NITZ特征时，网络可以向UE发送无法在UE上正确显示的网络信息。例如，UE可以连接到无线网络，该无线网络以UE上不支持或无法正确显示的格式向UE发送指示网络名称的字符的字符串。通常，在这种情况下，UE可能会显示诸如杂乱字符之类的错码或乱码，其没有向UE的用户提供有用的信息。

在其他一些情况下，当用户正在漫游时，可能会以用户不理解的语言向用户显示信息。例如，如果来自北美的用户漫游到中国，如果用户无法阅读中文字符，则以中文字符显示运营方名称可能无法向用户提供有关运营方的信息。同样，如果来自中国的用户漫游到北美，在用户的设备上显示拉丁字符可能无法向中国用户提供足够的信息。

已经进行了各种尝试来处理一些上述问题。在2013年8月20日的美国专利号8,515,422“Displaying Characters and Images Based On Support”中，该专利涉及跳过不可显示的标记。特别地，如果网络文本字符串中的字符是“垃圾”字符，则该专利教导了在显示运营方文本字符串时跳过这些字符。

在一种情况下，UE可以接收两种不同语言的字符并且不显示或跳过未在UE上设置的语言的字符。在这种情况下，该解决方案使用UE上配置的MMI来选择要显示的语言。人机界面是用户用来控制设备以设置设备语言的菜单。

这样的解决方案被进一步采用到3GPP IS 22.101规范中。特别地，该标准的第10版规定：

对于由NITZ提供的PLMN名称，使用当地语言(如中文、日文、韩文、越南文、阿拉伯文、印地文等)的非拉丁字符的运营商可以在本地语言字符之外还包括拉丁字符的网络名称。

对于由NITZ提供的PLMN名称，如果针对(多个)非拉丁字符的语言与UE的MMI的语言不匹配，则漫游的UE应该跳过显示非拉丁字符。如果这会导致PLMN名称中没有剩余的拉丁字符，则UE应跳过显示由NITZ提供的PLMN名称；存储在ME中的PLMN名称改为具有下一个优先级。

以上允许具有使用拉丁字符的MMI的UE的用户漫游到中国并看到以拉丁字符显示的网络名称。中国网络运营商会在发送给UE的消息中同时包括中文和拉丁文的网络名称，并且UE会跳过或不显示中文字符，因为在这种情况下这些字符与MMI中的英语言不匹配。

显示网络名称的另一个问题是关于字符歧义性。如本文中所使用的，术语“歧义”、“歧义性”等可以指代单个字符代码，它们可以被解码为不同语言中的不同字符。歧义字符是由歧义字符代码所编码的字符。无歧义字符代码是用单个代码只表示单个字符的字符代码。

因为如3GPP TS 23.038“Alphabets and Language-Specific Information”(v.15.0.0，2018年6月)中所定义的，GSM默认字母表不允许对某些语言进行编码，所以另一种编码方案被重新用于NITZ，如被定义为ISO/IEC 10646。虽然以下讨论集中在ISO/IEC10646标准中可能出现的歧义性，但是本公开不限于这种编码方案，并且因此，这种编码方案应该只被认为是示例并且下面描述的实施例可以适用于其他情况。

虽然ISO/IEC 10646编码方案确实允许对亚洲语言中的字符进行编码，但是对于由特定十六进制代码表示的亚洲语言字符存在一些歧义性。

特别地，现在参考下表1。

表1：编码字符中的歧义性

在表1中，表中的“X”符号指示对应行中的十六进制代码表示对应列中的语言的符号。如表1中所见，十六进制代码6811既可以表示简体中文字符，也可以表示繁体中文字符。类似地，十六进制代码6812可以表示简体中文字符、繁体中文字符或韩文字符。

十六进制代码688C可以表示简体中文字符、繁体中文字符、韩文字符或越南文字符。类似的示例存在于编码集中。

由于这些歧义性，UE有时可能无法确定当网络名称被提供给UE时应该使用的适当字符，并且UE可能显示不正确的字符。例如，如果UE接收到十六进制代码6812，则UE可以在想要显示韩文字符时显示中文字符，反之亦然。

编码字符的歧义性基于以下语言：中文、日文、韩文和越南文(“CJKV”)。对此的一种解决方案在2015年5月5日的美国专利号9,026,087“Solving Character DisplayAmbiguities”中被提供。该专利教导了基于由网络提供的其他信息的解析，诸如移动国家代码、移动网络代码、路由区域身份(RAI)或位置区域身份(LAI)以及其他此类信息。例如，如果使用MCC信息，那么下面的表2示出了MCC到CJKV表意文字语言映射表，表2表示3GPP TS24.008的表10.5.93a，“Mobile radiointerface Layer 3specification；Corenetworkprotocols；Stage 3”，v.16.2.0，2019年9月，标准。同一张表还出现在用于长期演进(LTE)网络的3GPP TS 24.301中，“Non-Access-Stratum(NAS)protocol for EvolvedPacketSystem(EPS)；Stage 3”，v.16.2.0，2019年9月，以及用于第五代(5G)核心网络的3GPP TS 24.501中，“Non-Access-Stratum(NAS)protocol for 5G System(5GS)；Stage3”，v.16.2.0，2019年9月。

表2：MCC到CJKV

然而，即使使用这些解决方案，关于字符显示也存在某些问题。特别地，3GPP TS22.101中的当前文本在某些情况下强制UE以拉丁文显示网络名称。例如，从日本漫游到中国的用户会在其UE上以拉丁字符显示网络名称。具体而言，在这种情况下，中国网络运营商已包括拉丁字符和中文的网络名称。但是，从日本漫游到中国的UE会基于现行标准跳过中文字符，并以日本用户可能无法理解的拉丁字符显示网络名称。

对此的一种通用解决方案将是允许与先前在3GPP TS 22.101中引入的功能性类似的对称功能性。如前所述，期望的结果是漫游的UE将仅显示与MMI的语言类型相对应的字符。在这种区分中，区别在于拉丁语言类型(其将被视为一种通用语言)和所有其他非拉丁语言。通过将拉丁语言视为一种语言，从英国漫游到法国的UE仍将显示例如法文的网络名称，如果这导致没有MMI的语言类型的剩余字母字符，那么不使用NITZ字符串，而是改为使用ME显示特征。在这种情况下，UE从中国漫游到日本会跳过日文字符但也会跳过拉丁字符。由于没有任何日文字符要显示，那么UE会跳过使用NITZ字符串进行显示，并且将改为使用ME显示特征。这样的ME显示特征可以包括使用日文字符。

综上所述，如果UE例如从中国漫游到美国，则UE将跳过拉丁字符。由于在NITZ中不会显示任何其他字母字符，因此UE将跳过NITZ显示字符并使用ME信息代替显示。

可能出现的另一个问题是关于非漫游场景。如果中国的运营方以中文和拉丁文发送名称，则来自该运营方的归属用户会以中文和拉丁文向本地用户显示网络名称，因为目前作为3GPP TS 22.101标准的跳过解决方案不适用于非漫游情况。对此的一种解决方案是将跳过字符扩展到非漫游UE。以此方式，中国归属用户将只看到为她的归属运营方所显示的中文字符。这也将迎合一个国家的用户将电话的语言设置为另一种语言的情况，因为该用户的母语与这个用户所居住的国家不同。

然而，即使这样的字符不形成母语字符集的一部分，跳过字符也可能导致问题。例如，在韩国，一家运营方的名称是“SKTelecom”。这韩文写为“SK

”。名称包括没有韩文字符翻译的字母“SK”。使用混合拉丁/非拉丁字符的运营方(如SK Telecom)可以发送网络名称诸如“SK

Telecom”，后跟中文的“SK Telecom”。从拉丁国家漫游的UE会正确显示“SK Telecom”。从中国漫游的UE会跳过拉丁文和韩文字符，并正确显示中文的网络名称。但是，如果将跳过的想法扩展到非漫游UE，则本地韩国UE将显示“

”，因为它将跳过字符“SK”，因为它们被认为是拉丁文。这对于本地用户来说看起来有点奇怪。

对于漫游到韩国并且其语言设置为韩文的UE会出现相同的问题。即使来自网络的下行链路信息包括语言指示符的字段或信息元素(IE)，上述内容仍然适用。

特别地，如果字符编码允许针对每个字符对语音进行编码，则UE将跳过被认为是不同语言的一部分的那些字母字符而不是字段。如果UE检测到接收到的字段中的一些字符来自与UE的MMI的语言不同的字符，那么UE可能会错误地认为与这些字符的语言相关的行为应用。

例如，具有韩文MMI的UE可能会错误地跳过在字段内以拉丁字符编码的字符“SK”。ISO/IEC 10646编码以这样一种方式完成，以使得通常每个字符都独立地用其关联语言进行编码。使用字符的代码或字符的代码范围，UE例如可以评估该字符实际上是拉丁文。上面的SK Telecom问题的示例突出了一个事实，即，通常需要将解决混合语言的要求的解决方案。

此外，即使从3GPP标准中移除“跳过字符”解决方案，仍可能需要附加的解决方案来解决上述问题。这是因为用户设备可能正在使用与运营方不同的语言，无论是在归属网络中还是在漫游时，并且都会看到以此类设备的用户可能无法理解的语言进行显示的网络名称。

此外，上述解决方案在所指示或显示的是网络的本地名称的假设下工作良好。换句话说，它是用户理解的本地语言的归属名称。然而，在用户漫游或者用户的语言与本地运营方的语言不同的情况下，那么会出现新的问题，可能需要不同的解决方案。

此外，在一些情况下，UE可以向网络指示语言偏好，这反过来将导致以MMI的语言发送NITZ消息以供UE显示。然而，在这种情况下，关于显示网络名称以及还可能考虑UE是否正在漫游，没有定义该特征和上述其他三个特征的相互优先级。

此外，当前未定义提供语言偏好和解决CJKV歧义性之间的相互影响。

此外，另一个问题是，对于一些拉丁或非拉丁的网络名称，这些名称可能包括一些特殊字符，包括空格“”、破折号“-”或者与号“&”。根据ISO 10646编码，特殊字符实际上不被视为拉丁字符。因此，如果运营方指示例如“AT&T”，那么从中国到美国的漫游UE将跳过拉丁字符，但是将显示字符“&”、“”、“-”，这可能会让用户感到厌烦。

基于所有这些问题，以下描述的实施例提供了各种解决方案。在一些实施例中，将解决方案建立在跳过不希望的字符解决方案之上。在其他一些实施例中，可以为各种信令字段提供语言指示符，并且UE可以基于MMI来显示与信令字段相对应的字符并且跳过嵌入在其他信令字段中的字符的显示。在进一步的实施例中，UE可以发送具有由用户设置的MMI的语言的指示的上行链路消息，并且反过来将以UE的MMI的语言接收下行链路消息。在这个示例中，UE可以使用MMI的语言来确定如何显示歧义字符。下面更详细地描述这些实施例中的每一个。

以上描述了网络名称的三个来源，即USIM、NITZ和ME。其中，USIM和ME由用户的归属运营商有效地提供，使NITZ成为访问运营商可以直接向UE提供信息的唯一机制。在这点上，下面的实施例将NITZ机制用于网络名称。然而，这并不意味着是限制性的，并且本领域技术人员将认识到本文描述的各种实施例同样可以与其他信令机制一起使用并且因此不限于NITZ。

示例架构

现在对图1进行参考，其示出了根据本公开的简化网络图。在图1中，用户设备110与网络通信，在图1的简化实施例中网络包括无线接入网络120(包括但不限于基站、节点B、演进型节点B(eNB)或下一代节点B(gNB))和核心网络122，其包括归属订户服务器(HSS)/归属位置注册表(HLR)或访问位置注册表(VLR)124，这取决于无线电接入网络是UE 110的归属网络还是访问网络。

如果无线电接入网络120是访问网络，则UE 110可以尝试连接到访问网络并对其进行认证。这通过VLR 124通过发送身份(诸如UE的归属网络IMSI)来完成，VLR 124然后使用诸如GLa接口之类的接口通过网络来与HSS/HLR 140通信，并获得如上关于图1所述的认证向量。然后使用质询和响应来认证UE 110。

否则，如果网络120是归属网络，则使用HSS/HLR 124完成认证和附接。

然后可以从UE 110通过网络120和核心网络122将数据路由到互联网150(或到任何其他数据网络)。

在跳过不希望的字符之上的信令

根据本公开的一个实施例，作为3GPP TS 22.101要求的例外，可以在信令中引入信息以指示字符集禁止被跳过。当MMI是非拉丁文时，这将允许用户避免跳过自然地作为网络名称一部分的一些拉丁字符。

因此对图2进行参考。在图2的实施例中，网络元件210与UE 212通信。

网络元件可以向UE 212发送与消息220一起示出的信令。在这种情况下，信令可以是网络元件和UE之间的任何信令，并且可以包括信息元素、控制信令以及其他信令。

在一些实施例中，消息220中的信令可以包括额外位。参考图3，消息310包括常规信令位320以及附加位322。附加位322在一些情况下可以意指：

0-无信息；

1-忽略跳过3GPP TS 22.101的要求。

虽然以上是一个示例，但其他措辞是可能的。

在该情况下，当UE在消息220或消息310中接收到信令时，UE可以查看附加位并将其行为基于这个附加位。特别地，如果附加位指示零，那么UE可以执行3GPP TS 22.101的要求并忽略拉丁字符。相反，如果该位指示一，那么UE可以将非拉丁字符与拉丁字符结合起来并显示所有这些字符。

除了或代替图2和图3的上述实施例中的附加位的含义，来自图3的附加位322可以意指：

0-无信息；

1-跳过(多个)字符集，即使3GPP TS 22.101要求显示该集。

针对位的上述替代含义可以被用于对称问题，以使得例如当日本移动用户漫游到中国时可以使用它。

虽然上面图2和图3的各种实施例可以应用于在UE处显示的任何消息中，但是在一些实施例中，信息的应用性可以基于每个显示特征。例如，实施例可以仅在一些情况下应用于NITZ显示。

换句话说，如果一个或多个拉丁字符来自基于上面定义的位的另一种语言，则UE应该考虑一个或多个拉丁字符。例如，在上述SK telecom情况中，UE在跳过要求过程中应将拉丁字符视为韩文字符。这不会影响拉丁字符(如果被显示)以拉丁文显示的事实。换句话说，这种拉丁字符没有翻译。

因此，信息位的含义可以被解释为：

0-无信息

1-在“跳过过程”中将此字符视为韩文。

在上述情况下，信息位可能需要与每个字符相关联，并且图3的实施例可以适于具有多个附加位。因此，字符串可能需要预定数目的位来传达字符以及为每个字符附加位以指示应如何处理该字符。

然而，这种替代方式可能需要大量位来对所有非拉丁语言进行编码。虽然这在一些情形中可能是可以接受的，但是在其他情形中，这种增加的位数可能是有问题的。在这种情况下，另一种解决方案可以是：附加位322可以是：

0-无信息；

1-将此IE中的所有拉丁字符视为与此IE中包括的(多个)非拉丁语言字符相同的语言。

如对本领域技术人员显而易见的，以上基于网络运营商在IE中仅包括来自一种非拉丁语言的字符的第一假设。因此，代替IE，可以考虑其他假设或粒度，诸如使用信令字段。在一个示例中，可以使用ASN.1字段。

诸如上述的信令位可以在多个下行链路消息中被实现。示例包括：对于2G或3G(3GPP TS 24.008)：移动管理(MM)信息消息、通用分组无线服务(GPRS)移动管理(GMM)信息消息、临时移动用户身份(TMSI)REALLOCATION COMMAND消息、IDENTITY REQUEST消息、LOCATION UPDATING ACCEPT消息、ATTACH ACCEPT消息。对于长期演进/增强型分组核心(LTE/EPC)(3GPP TS 24.301)：增强型分组服务(EPS)移动管理(EMM)信息消息、GUTIREALLOCATION COMMAND消息、AUTHENTICATION REQUEST消息、SECURITY MODE COMMAND消息、IDENTITY REQUEST消息、DETACH ACCEPT消息、DETACH REQUEST消息、TRACKING AREAUPDATE ACCEPT消息、TRACKING AREA UPDATE REJECT消息。对于5G核心网络(TS24.501)：CONFIGURATION UPDATE COMMAND消息、REGISTRATION ACCEPT消息、DEREGISTRATIONREQUEST消息、REGISTRATION REJECT消息、IDENTITY REQUEST消息、AUTHENTICATIONREQUEST消息。也可以使用其他消息。

在其他一些情况下，可以出于这种信令的目的而创建新的下行链路消息。

此外，虽然上述实施例是关于3GPP系统描述的，但是根据本公开，实施例不限于这样的3GPP系统并且可以被重新应用于其他系统，包括但不限于，Wi-Fi、WiMAX、IEEE802.11、热点2.0等。此外，即使本公开中的示例提供了网络名称，消息也不需要与网络名称相关。

在其他一些实施例中，可以在没有信令的情况下执行改变，例如，在一种情况下，3GPP TS 22.101规范可以被更改(如粗体所示)为：

“对于由NITZ提供的PLMN名称，使用当地语言(如中文、日文、韩文、越南文、阿拉伯文、印地文等)的非拉丁字符的运营商可以在本地语言字符之外还包括拉丁字

符的网络名称。

对于由NITZ提供的PLMN名称，如果针对(多个)非拉丁字符的语言与UE的MMI的语言不匹配，则漫游的UE应该跳过显示非拉丁字符。在此过程中，如果接收到(多个)非拉丁字符，则UE应将NITZ的网络名称中的所有拉丁字符视为来自与(多个)非拉丁字符相同的语言。如果这会导致PLMN名称中没有剩余的拉丁字符，则UE应跳过显示由NITZ提供的PLMN名称；存储在ME中的PLMN名称具有下一个优先级。”

在替代实施例中，3GPP TS 22.101规范可以被更改为：

“对于由NITZ提供的PLMN名称，使用当地语言(如中文、日文、韩文、越南文、阿拉伯文、印地文等)的非拉丁字符的运营商可以在本地语言字符之外还包括拉丁字符的网络名称。

对于由NITZ提供的PLMN名称，如果针对(多个)非拉丁字符的语言与UE的MMI的语言不匹配，则漫游的UE应该跳过显示非拉丁字符。在此过程中，如果接收到(多个)非拉丁字符，则UE应将在与(多个)非拉丁字符相同的信息元素中发送的所有拉丁字符视为来自与非拉丁字符相同的语言。如果这会导致PLMN名称中没有剩余的拉丁字符，则UE应跳过显示由NITZ提供的PLMN名称；存储在ME中的PLMN名称具有下一个优先级。”

根据以粗体显示的上述更改，NITZ网络名称或信息元素中的所有拉丁字符将被视为与其余字符相同的语言。

除了上述之外，一个问题可能是一些网络名称，无论是拉丁文还是非拉丁文，其可能包括特殊字符，诸如空格“”、破折号“-”或者与号“&”。根据ISO 10646编码，特殊字符实际上不被视为拉丁字符。因此，如果运营商指示例如“AT&T”，那么上述要求将导致在UE从中国漫游到美国的情况下，显示字符“&”、“”或“-”，因为电话将跳过拉丁字符，但是仍将显示此类特殊字符。这样的结果可能会让用户感到厌烦。因此，3GPP IS 22.101可以被修改如下：

“对于由NITZ提供的PLMN名称，如果针对(多个)非拉丁字符的语言与UE的MMI的语言不匹配，则漫游的UE应该跳过显示非拉丁字符。在此过程中，在同一语言的(多个)字符之间接收到的任何非字母字符都应视为来自该语言的(多个)字符。如果这会导致PLMN名称中没有剩余的拉丁字符，则UE应跳过显示由NITZ提供的PLMN名称；存储在ME中的PLMN名称具有下一个优先级。”

此外，代替3GPP IS 22.101，可以将要求添加到其他技术标准，诸如3GPP TS24.008。例如，可以在消息编码或IE编码中引入新要求。新要求可以用另一种语言示例读为：

“将此IE中的所有字符(甚至非字母字符)视为韩文字母字符”

另一个示例假设语言鉴别符被添加到3GPP TS 24.008信令。例如，语言鉴别符可以应用于MM/GMM信息消息中的每个新IE，或者应用于被引入的新下行链路消息。那么添加到3GPP TS 24.008的新要求可以被改写为：

“将此IE中的所有字符(甚至非字母字符或来自不同语言的字符)视为来自相同语言的字母字符而不是语言鉴别符”

其他措辞或示例解决方案是可能的。

以上将因此解决上述非语言字符跳过问题和上述拉丁文/韩文问题。

向信令字段提供语言指示符

在进一步的实施例中，网络元件可以向UE发送不同的信令字段。特别地，现在对图4进行参考，其中网络元件410与UE 412通信。在图4的示例中，消息420提供一个或多个信令字段，其中每个信令字段用语言指示符来标识。UE可以选择与与在UE的MMI中设置的语言相对应的语言指示符相对应的信令字段。

具体地，对图5进行参考，其示出了多个信令字段510，每个信令字段具有其自己的语言指示符512。UE然后可以显示与对应于设备的MMI的信令字段相对应的字符并跳过嵌入在其他信号字段中的字符的显示。

因此，根据图4和图5的实施例，在不同信令字段中接收的字符之间执行选择，但是该信令字段中的所有字符将被显示在UE上。这包括包含反映其他语言的字符编码的字符或非字母字符。如果通过使用与每个信令字段相对应的语言指示符没有与MMI的语言相对应的信令字段，则UE不使用对应的显示特征并使用优先级列表中的下一个。

在一个特定示例中，UE可以利用新特征，在本文中被称为“NITZ2”或“网络名称2”。如果所选择的此类字段的语言指示符包括UE的MMI的语言，那么来自该字段中的网络名称可以被用于显示。

相反，如果不存在此类字段，那么UE将不使用该特征，而是根据优先级列表使用ME显示特征。

在由设备使用的显示特征的优先级中，NITZ2显示特征可以位于不同的优先级点处。在一个实施例中，新的显示特征可以位于USIM和ME显示之间，就像当前针对NITZ的情况一样，但是会位于当前的NITZ之前。换句话说，显示特征从最高优先级到最低优先级可以是：

1.USIM网络名称显示；

2.诸如NITZ2之类的新显示特征；

3.NITZ网络名称显示；

4.ME网络名称显示。

然而，其他优先级是可能的。例如，在一种替代方案中，当UE不漫游时，NITZ可具有比新显示特征更高的优先级。相反，当UE漫游时，NITZ2可具有高于NITZ的优先级。在另一个替代方案中，当UE不漫游时，NITZ可具有低于新显示特征的优先级；当UE漫游时，NITZ2可具有低于NITZ的优先级。

此外，在一些情况下，可以仅在用户漫游时使用新的显示特征。

在其他一些情况下，新显示特征的优先级可以由用户选择和/或由网络用信号通知。如果用户和网络都可以选择，那么用户选择可以优先于网络选择，反之亦然。

如果网络正在选择，那么在一个示例中，网络可以向UE提供两位字段参数。该字段可以采取十进制值1到4，指示NITZ2特征与其他优先级相比的相对优先级。例如，“1”可指示NITZ2特征将具有高于USIM的最高优先级。“2”将意指优先级将落在USIM和NITZ之间。“3”将意指优先级将落在NITZ和ME之间。“4”将指示低于ME的最低优先级。

在图4和图5的实施例中，术语“信令字段”被用作通用术语。这样的信令字段可以是例如消息内的信息元素，或消息内的信息元素内的字段。换句话说，一个信息元素中可以包括一个以上的信令字段。

此外，在一些情况下，该字段可以是消息内的ASN.1字段或CSN.1字段。

在一些情况下，可以经由诸如3GPP TS 24.008、3GPP TS 24.301或3GPP TS24.501之类的L3信令解决方案将信息提供给设备。

在其他一些情况下，可以经由开放移动联盟(OMA)设备管理(DM)或SIM工具包应用将信息提供给UE/USIM。

因此，基于以上，实施例可以在由两个不同的显示特征所提供的两个信令字段之间使用。例如，这可适用于由NITZ提供的网络名称和由诸如NITZ2之类的新显示特征提供的一个或多个网络名称之间。在一个示例中，UE将显示来自NITZ2的网络名称而不是来自NITZ的网络名称，因为来自NITZ2的网络名称是MMI的语言，而来自已经存在的NITZ的网络名称可能不是MMI的语言。

在另一个示例中，选择是使用NITZ还是NITZ2可以是一个条件。具体来说，如果新显示特征包含MMI的语言的网络名称，那么新显示特征可能优先于NITZ。否则，NITZ将优先于NITZ2。在另一示例中，如果新显示特征包含MMI的语言的网络名称，那么新显示特征可能优先于其他显示特征，诸如USIM特征。

在另一个示例中，如果NITZ2不包括MMI的语言的网络名称，那么在所有显示特征之中完全跳过或不使用NITZ2。

在又一个实施例中，NITZ2优先级在已经存在的显示特征之中受到影响，这取决于NITZ2是否包含MMI的语言的网络名称。

此外，在一些情况下，可以添加关于UE是否正在漫游的概念，从而影响新显示特征的整体优先级以及可能影响现有NITZ的优先级。

此外，关于“CJKV歧义”，在一个实施例中，UE使用由语言指示符指示并且应该与MMI的语言相对应的语言，因为只有对应的网络名称与NITZ2相关联。因此，歧义性被解决。

以上可以在各种信令解决方案中实现。可以在标准中做出各种更改请求。例如，消息可以是但不限于：对于2G或3G(3GPP TS 24.008)：移动管理(MM)信息消息、通用分组无线服务(GPRS)移动管理(GMM)信息消息、临时移动用户身份(TMSI)REALLOCATION COMMAND消息、IDENTITY REQUEST消息、LOCATION UPDATING ACCEPT消息、ATTACH ACCEPT消息。对于长期演进/增强型分组核心(LTE/EPC)(3GPP TS 24.301)：增强型分组服务(EPS)移动管理(EMM)信息消息、GUTI REALLOCATION COMMAND消息、AUTHENTICATION REQUEST消息、SECURITY MODE COMMAND消息、IDENTITY REQUEST消息、DETACH ACCEPT消息、DETACHREQUEST消息、TRACKING AREA UPDATE ACCEPT消息、TRACKING AREA UPDATE REJECT消息。对于5G核心网(TS 24.501)：CONFIGURATION UPDATE COMMAND消息、REGISTRATION ACCEPT消息、DEREGISTRATION REQUEST消息、REGISTRATION REJECT消息、IDENTITY REQUEST消息、AUTHENTICATION REQUEST消息。也可以使用其他消息。

可以对3GPP TS 24.008做出的更改的一个示例在下面的附录A中关于粗体部分示出。本领域技术人员应注意，这种更改也将涵盖LTE和5G，因为LTE和5G中的信息元素，即3GPP TS 24.301和3GPP TS 24.501也将指向3GPP TS 24.008中定义的信息元素。

如附录A的示例中所示，可以添加粗体项目。即用于network2(网络2)的完整网络名称和用于network2(网络2)的缩写网络名称。

如在附录A中进一步所见，完整网络名称和缩写网络名称被定义，以及对基于语言鉴别符来使用哪个网络名称2的定义。

在附录A的更改中，提供了新的信息元素，如本公开的图6中所示。

此外，可以对3GPP TS 24.301进行更改，如下面的附录B中所示。如附录B中所见，对该标准的新增内容以粗体示出，与上述内容类似。

此外，还可以对3GPP TS 24.501进行更改，这些更改在下面的附录C中以粗体示出。此类更改与上述关于附录A或附录B的更改类似。

此外，针对国家/PLMN指示对3GPP TS 22.101的更改在下面关于附录D示出。特别地，更改以粗体示出并引入了NITZ2。

UE向网络指示MMI的语言

在本公开的另一个实施例中，UE可以向网络发送上行链路消息，以提供MMI的语言的指示，该MMI的语言由用户在该UE上设置或曾经设置。这样做是为了解决语言不理解的问题。进而，可以向UE提供下行链路消息，其中UE接收文本字符串以供UE以UE的MMI的语言来进行显示。

此外，以下描述的实施例针对此概念提供了附加特征。

在当前情况下，如果UE接收到包括包含一个或多个歧义字符的文本字符串的消息，则UE可以使用MMI的语言来确定如何显示歧义字符。这不同于现有的解决方案，在现有的解决方案中UE使用在PLMN ID中从网络接收到的来自MCC所在国家的语言。

特别地，现在对图7进行参考。在图7的实施例中，网络元件710与UE 712通信。

在图7的情况下，UE 712提供指示这种UE的MMI的语言的消息720。作为响应，消息730中的信令包括MMI的语言的信息。

如果消息730包括歧义字符，则UE 712使用MMI的语言来确定如何显示歧义字符，如块740处所示。

关于消息730中的信息的特征优先级可以与上述类似地进行处理。特别地，特征优先级可以被设置在现有三个优先级之间的任何位置，并且可以由用户或网络设置。如果优先级由网络设置，那么优先级可以基于由网络提供的两位字段来指示优先级应该在哪里。

在其他一些情况下，可以预先确定或者可以基于UE是否正在漫游来设置优先级。

基于本公开的其他示例对于本领域技术人员将是显而易见的。

此外，可以在本实施例中实现上述第一实施例中关于在跳过字符之上的实施例的解决方案。在本实施例的情况下，措辞在各种标准中可能略有不同。例如，可以向3GPP TS24.008添加一个新要求，该要求可以被改写如下：

“将此IE中的所有字符(甚至非字母字符或来自不同语言的字符)视为来自MMI的语言的字母字符”

其他措辞或示例解决方案是可能的。

为了解决“CJKV歧义性”，对于相关的歧义字符，在一个示例实施例中，UE可以使用UE的MMI的语言，其应该对应于被网络用于网络名称字段的语言。

以上可以通过各种更改来实现。例如，附录E以粗体示出了对3GPP TS 22.101规范的一个示例更改，其包括字符跳过。在此示例中，应完整显示由NITZ2提供的PLNN，即使此类名称包括非字母字符或使用与MMI不同的语言进行编码的字符。

关于下面的附录F，以粗体提供了另一个示例。在此示例中，之前在2019年引入3GPP TS 22.101规范的字符跳过已被移除。相反，NITZ2被指示优先于NITZ，并且所提供的所有字符都应该被视为在所指示的MMI的语言中。

此外，在本实施例中，对3GPP TS 24.301的更改可以与附录B中提供的那些相同。

类似地，在本实施例中，对3GPP TS 24.501的更改可以与附录C中提供的那些相同。

可以对3GPP TS 24.008进行更改以包括网络名称2，如下面的附录G中以粗体所示。在这个更改中，提供了一个新的信息元素，如本公开的图8中所示。

以上内容因此提供了以适合于用户设备的用户的语言显示字符。

可以使用任何用户设备来实现上述内容。下面关于图9示出了一个示例用户设备。

UE 900可以是具有语音和数据通信能力的双向无线通信设备。取决于所提供的具体功能性，UE例如可以被称为数据消息设备、双向寻呼机、无线电子邮件设备、具有数据消息收发能力的蜂窝电话、无线互联网设备、无线设备、移动设备或数据通信设备、物联网端点。

在启用UE 900进行双向通信的情况下，它可以并入了通信子系统911，该通信子系统911包括接收器912和发射器914，以及诸如一个或多个天线元件916和918、本地振荡器(LO)913之类的关联组件以及诸如数字信号处理器(DSP)920之类的处理模块。尽管未被示出，通信子系统911可以包括附加组件。例如，UE 900可以包括多个接收器912和/或发射器914以允许同时进行无线电活动。此外，对于通信领域的技术人员来说显而易见的是，通信子系统911的特定设计将取决于设备打算在其中操作的通信网络。

网络接入要求也将取决于网络919的类型而变化。在一些网络中，网络接入与UE900的订户或用户相关联。UE可能需要一个或多个智能卡，诸如UICC，以便在网络上操作。智能卡接口944通常类似于可以插入和弹出智能卡的卡槽。智能卡可以具有存储器并保存许多密钥配置951和其他信息953，诸如标识和订户相关信息。

当所需的网络注册或激活过程已经完成时，UE 900可以通过网络919发送和接收通信信号。如图9中所图示，网络919可以由与UE通信的多个基站组成。

天线916通过通信网络919接收的信号被输入到接收器912，接收器912可以执行诸如信号放大、下变频、滤波、信道选择等常见的接收器功能。接收信号的A/D转换允许在DSP920中执行更复杂的通信功能，诸如解调和解码。以类似的方式，要被发射的信号由DSP 920处理，例如包括调制和编码，然后被输入到发射器914以用于数模转换、上变频、滤波、放大并且经由天线918通过通信网络919传输。DSP 920不仅处理通信信号，而且提供接收器和发射器控制。例如，可以通过在DSP 920中实现的自动增益控制算法来自适应地控制被应用于接收器912和发射器914中的通信信号的增益。

UE 900通常包括处理器938，其控制设备的整体操作。通过通信子系统911执行通信功能，包括数据和语音通信。处理器938还与其他设备子系统交互，诸如显示器922、闪存924、随机存取存储器(RAM)926、辅助输入/输出(I/O)子系统928、串行端口930、一个或多个键盘或小键盘932、扬声器934、麦克风936、诸如短程通信子系统之类的其他通信子系统940和通常被指定为942的任何其他设备子系统。串行端口930可以包括USB端口或本领域技术人员已知的其他端口。

图9中所示的一些子系统执行与通信相关的功能，而其他子系统可以提供“常驻”或设备上的功能。值得注意的是，一些子系统，诸如键盘932和显示器922，例如可以被用于与通信相关的功能，诸如输入文本消息以通过通信网络传输，以及被用于设备驻留功能，诸如计算器或任务列表。

由处理器938使用的操作系统软件可以被存储在诸如闪存924之类的持久存储库中，闪存924可以替代地是只读存储器(ROM)或类似的存储元件(未示出)。本领域技术人员将了解，操作系统、特定设备应用或其部分可以被临时加载到诸如RAM 926之类的易失性存储器中。接收到的通信信号也可以被存储在RAM 926中。

如图所示，闪存924可以被划分为用于计算机程序958和程序数据存储950、952、954和956的不同区域。这些不同的存储类型指示每个程序可以为其自己的数据存储要求而分配闪存924的一部分。处理器938除了其操作系统功能外，还可以实现在UE上执行软件应用。控制基本操作的一组预定应用，例如至少包括数据和语音通信应用，通常将在制造期间就被安装在UE 900上。其他应用可以随后或动态地安装。

应用和软件可以被存储在任何计算机可读存储介质上。计算机可读存储介质可以是有形或瞬态/非瞬态介质，诸如光存储器(例如，CD、DVD等)、磁存储器(例如，磁带)或本领域已知的其他存储器。

在数据通信模式下，诸如文本消息或网页下载之类的接收信号将由通信子系统911处理并输入到处理器938，处理器938可以进一步处理接收信号以输出到显示器922，或者替代输出到辅助I/O设备928。

结合显示器922和可能的辅助I/O设备928UE 900的用户还可以例如使用键盘932，来编写诸如电子邮件消息之类的数据项，键盘932可以是完整的字母数字键盘或电话型小键盘等。在其他一些情况下，键盘932可以是显示器922上的虚拟键盘。然后可以通过通信子系统911在通信网络上传输这样的组合项。

对于语音通信，UE 900的总体操作是相似的，除了接收到的信号通常将被输出到扬声器934并且用于传输的信号将由麦克风936生成。替代的语音或音频I/O子系统，诸如语音消息记录子系统也可以在UE 900上被实现。虽然语音或音频信号输出通常主要通过扬声器934来完成，但是显示器922也可以被用来提供呼叫方身份、语音呼叫的持续时间或其他语音呼叫相关信息的指示。

图9中的串行端口930可以被用于多种目的，包括与用户的台式计算机(未示出)同步，使得用户能够通过外部设备或软件应用来设置偏好，并且通过向UE 900提供信息或软件下载而不是通过无线通信网络来扩展UE 900的能力。例如，替代的下载路径可以被用来通过直接且因此可靠且受信任的连接将加密密钥加载到设备上，从而实现安全设备通信。如本领域技术人员将了解的，串行端口930还可以被用来将UE连接到计算机以充当调制解调器，或者可以被用于为设备充电。

诸如短程通信子系统之类的其他通信子系统940是可以提供UE 900和不同系统或设备之间的通信的另外可选组件，这些系统或设备不一定是相似的设备。例如，子系统940可以包括红外设备和关联的电路与组件或Bluetooth^TM通信模块以提供与类似启用的系统和设备的通信。子系统940还可以包括非蜂窝通信，诸如WiFi或WiMAX。

此外，本文提及和示出的网络元件可以是任何网络元件或任何网络元件的一部分，包括各种网络服务器。现在对图10进行参考，它示出了一个通用的示例网络元件。

在图10中，网络元件1010包括处理器1020和通信子系统1030，其中处理器1020和通信子系统1030协作以执行上述实施例的方法。

处理器1020被配置为执行可编程逻辑，该可编程逻辑可以与数据一起被存储在网络元件1010上，并且在图10的示例中被示为存储器1040。存储器1040可以是任何有形存储介质。

替代地或者除了存储器1040之外，网络元件1010还可以例如通过通信子系统1030从外部存储介质访问数据或可编程逻辑。

通信子系统1030允许网络元件1010与其他网络元件进行通信。

在一个实施例中，网络元件1010的各种元件之间的通信可以通过内部总线1050。然而，其他形式的通信也是可能的。

本文所述和附图中所示的特定实施例的结构、特征、附件和替代方案旨在一般性地适用于包括本文所述和图示的所有实施例在内的本公开的所有教导，只要它们是兼容的。换言之，除非如此指明，否则特定实施例的结构、特征、附件和替代方案不旨在仅限于该特定实施例。

此外，本领域技术人员将理解本公开的附加特征和优点。

本文描述的实施例是具有与本申请的技术的元素相对应的元素的结构、系统或方法的示例。该书面描述可以使本领域技术人员能够制作和使用具有同样与本申请的技术的元素相对应的替代元素的实施例。因此，本申请的技术的预期范围包括与本文所述的本申请的技术没有区别的其他结构、系统或方法，并且还包括与如本文描述的本申请的技术没有本质区别的其他结构、系统或方法。

附录A-对3GPP TS 24.008的更改示例

9.2.15a MM信息

该消息由网络发送到移动台以向移动台提供订户特定信息。参见表9.2.18/3GPPTS 24.008。

消息类型： MM INFORMATION(MM信息)

意义：双重

方向：网络到移动台

表9.2.18/3GPP TS 24.008MM INFORMATION(MM信息)消息内容

9.2.15a.1网络的完整名称

该IE可以由网络发送。如果此IE被发送，则此IE的内容指示“网络的完整名称”，网络希望移动台将“网络的完整名称”与包含在移动台将其信道请求消息发送到的小区的位置区域标识中的MCC和MNC相关联。

9.2.15a.2网络的缩写名称

该IE可以由网络发送。如果此IE被发送，则此IE的内容指示“网络的缩写名称”，网络希望移动台将“网络的缩写名称”与包含在移动台将其信道请求消息发送到的小区的位置区域标识中的MCC和MNC相关联。

9.2.15a.3本地时区

该IE可以由网络发送。移动台应该假设这个时区适用于信道请求消息被发送到的小区的位置区域。

如果本地时区已针对夏令时进行了调整，则网络应通过包括IE网络夏令时来指示这一点。

9.2.15a.4世界时和本地时区

该IE可以由网络发送。移动台应该假设这个时区适用于信道请求消息被发送到的小区的位置区域。移动台不应假定时间信息是准确的。

9.2.15a.5LSA身份

该IE可以由网络发送。该IE的内容指示服务小区的LSA身份。

9.2.15a.6网络夏令时

该IE可以由网络发送。如果此IE被发送，则此IE的内容指示已被用来调整本地时区的值。

9.2.15a.7网络的完整名称2

9.2.15a.8网络的缩写名称2

该IE可以由网络发送。如果此IE被发送，则此IE的内容指示“网络的缩写名称”，网络希望移动台将“网络的缩写名称”与包含在移动台将其信道请求消息发送到的小区的位置区标识中MCC和MNC相关联。

(...)

a.b.c.d网络名称2

除了在信息元素网络名称中提供的文本字符串之外，该信息元素的目的是将文本字符串传递给移动台。

网络名称2信息元素的编码如图x1.y1.z1/3GPP TS 24.008和表x2.y2.z2/3GPPTS 24.008中所示。

出于3GPP TS 22.101[8]附录A.3中指定的网络名称显示要求的目的，MS应将与语言鉴别符相关联的所有字符(甚至是非语言字符或具有编码指示不同语言的字符)视为来自语言鉴别符的语言的字母字符。

如果使用编码方案UCS2并且在文本字符串中接收到ISO/IEC10646[72]中定义的中-日-韩-越南(CJKV)表意文字，则MS应使用[Alt1:对应的语言指示符][Alt2:MMI的语言]来确定用于那些CJKV表意文字的语言。

注意：这是由于UCS2中的CJKV表意文字语言歧义性，即相同的十六进制代码可以被映射到不同的字符显示，具体取决于所使用的语言。CJKV表意文字的编码本身不允许鉴别CJKV表意文字语言。

网络名称2是类型4信息元素，最小长度为3个八位字节。除了由L3消息中的最大八位字节数给出的长度限制(参见3GPP TS44.006[19])之外，没有指定长度上限。

图x1.y1.z1/3GPP TS 24.008网络名称2信息元素——对于该图，参见本公开的图6。

表x2.y2.z2/3GPP TS 24.008网络名称2信息元素

附录B-对3GPP TS 24.301的更改示例

8.2.13 EMM信息

8.2.13.1 消息定义

该消息由网络在EMM上下文建立期间的任何时间发送，以向UE发送某些信息。参见表8.2.13.1。

消息类型： EMM信息

意义：本地

方向：网络到UE

表8.2.13.1：EMM信息消息内容

IEI	信息元素	类型/参考	存在	格式	长度
							协议鉴别符	协议鉴别符9.2	M	V	1/2
	安全报头类型	安全报头类型9.3.1	M	V	1/2
							EMM信息消息类型	消息类型9.8	M	V	1
43	网络的完整名称	网络名称9.9.3.24	O	TLV	3-n
						45	网络的缩写名称	网络名称9.9.3.24	O	TLV	3-n
46	本地时区	时区9.9.3.29	O	TLV	2
						47	世界时和本地时区	时区与时间9.9.3.30	O	TLV	8
49	网络夏令时	夏令时9.9.3.6	O	TLV	3
						tbd	网络的完整名称2	网络名称2A3.b3.c3.d	O	TLV	3-n
tbd	网络的缩写名称2	网络名称2A3.b3.c3.d	O	TLV	3-n

8.2.13.2网络的完整名称

该IE可以由网络发送。如果此IE被发送，则此IE的内容指示“网络的完整名称”，网络希望UE将“网络的完整名称”与包含在最后访问的跟踪区域标识中的MCC和MNC相关联。

8.2.13.3网络的缩写名称

该IE可以由网络发送。如果此IE被发送，则此IE的内容指示“网络的缩写名称”，网络希望UE将“网络的缩写名称”与包含在最后访问的跟踪区域标识中的MCC和MNC相关联。

8.2.13.4本地时区

该IE可以由网络发送。UE应该假设这个时区适用于当前小区的跟踪区域，并且如果在UE中可用，也适用于跟踪区域列表。

注意：时间信息可能不准确，尤其是当TAI列表包括属于不同时区的跟踪区域时。

如果本地时区已针对夏令时进行了调整，则网络应通过包括网络夏令时IE来指示这一点。

8.2.13.5世界时和本地时区

该IE可以由网络发送。UE应该假设这个时区适用于UE当前所在的跟踪区域，并且如果在UE中可用，也适用于跟踪区域列表。UE不应假设时间信息是准确的。

8.2.13.6网络夏令时

8.2.13.7网络的完整名称2

8.2.13.8网络的缩写名称2

(……)

9.9.3.24网络名称2

参见3GPP TS 24.008[13]中的子条款a.b.c.d。

附录C-对3GPP TS 24.501的示例更改

8.2.19配置更新命令

8.2.19.1消息定义

配置更新命令消息由AMF发送给UE。参见表8.2.19.1.1。

消息类型：配置更新命令

意义：双重

方向：网络到UE

表8.2.19.1.1：配置更新命令消息内容

8.2.19.2配置更新指示

如果AMF需要向UE请求确认或注册过程，则AMF应包括此IE。

8.2.19.3 5G-GUTI

此IE可以被包括以将新的5G GUTI分配给UE。

8.2.19.4 TAI列表

此IE可以被包括以将新的TAI列表分配给UE。

8.2.19.5允许的NSSAI

此IE可以被包括以向UE分配新的允许的NSSAI。

8.2.19.6服务区域列表

此IE可以被包括以向UE分配新的服务区域列表。

8.2.19.7网络的完整名称

此IE可以被包括以为UE分配新的网络完整名称。

8.2.19.8网络的缩写名称

此IE可以被包括以为UE分配新的网络缩写名称。

8.2.19.9本地时区

此IE可以被包括以向UE分配新的本地时区。

8.2.19.10世界时和本地时区

此IE可以被包括以向UE分配新的世界时和本地时区。

8.2.19.11网络夏令时

此IE可以被包括以向UE分配新的网络夏令时。

8.2.19.12LADN信息

此IE可以被包括以向UE分配新的LADN信息或者在UE侧删除LADN信息。

8.2.19.13MICO指示

此IE可以被包括以请求UE重新协商MICO模式。

8.2.19.14网络切片指示

如果用户的网络切片订阅在UDM中发生了变化，则该IE应被包括。

8.2.19.15配置的NSSAI

当AMF需要为当前PLMN向UE提供新配置的NSSAI时，AMF应包括此IE。

8.2.19.16拒绝的NSSAI

网络可以包括此IE以通知UE：先前在允许的NSSAI中发送给UE但现在被认为被网络拒绝的S-NSSAI。

8.2.19.17运营商定义的接入类别定义

此IE可以被包括以向UE分配新的运营商定义的接入类别定义或删除在UE侧的运营商定义的接入类别定义。

8.2.19.18SMS指示

此IE可以被包括以指示UE通过NAS使用SMS的能力已经改变。

8.2.19.19

此IE可以被包括以向UE分配新的T3447值。

8.2.19.20网络的完整名称

此IE可以被包括以向UE分配新的网络完整名称。

8.2.19.21网络的缩写名称

此IE可以被包括以向UE分配新的网络缩写名称。

(...)

A2.b2.c2.d2网络名称2

参见3GPP TS 24.008[12]中的子条款a.b.c.d。

附录D-对3GPP TS 22.101的示例更改

A.3国家/PLMN指示

国家/PLMN指示符示出了UE当前在哪个PLMN中注册。该指示符是必要的，以使得用户知道“漫游”何时发生并且PLMN的选择是正确的。国家和PLMN都将被指示。当在给定区域中有多于一个的访问PLMN可用时，将指示此类信息。

PLMN名称是：

-存储在ME中并与广播信道上接收到的MCC+MNC组合相关联；

10-NITZ/NITZ2(参见22.042[17])(在这种情况下，它会覆盖存储在ME中的名称)；

-以文本和/或图形格式存储在USIM中并与MCC+MNC组合以及可选的LAI相关联，在广播信道上被接收(在这种情况下，它会覆盖存储在UE中的名称以及-如果存在的话-NITZ名称)。

应该可以在USIM上存储至少10个PLMN标识(MCC+MNC组合和可选的LAI)，针对它们应显示相同的PLMN名称。

存储在USIM中的PLMN名称具有最高优先级，其次是由NITZ/NITZ2提供的PLMN名称。存储在ME中的PLMN名称具有最低优先级。

如果USIM中存储的PLMN名称以文本格式不可用并且UE无法显示图形格式，则由NITZ/NITZ2提供的PLMN名称具有最高优先级，ME中存储的PLMN名称具有下一个优先级。

对于由NITZ提供的PLMN名称，使用当地语言(如中文、日文、韩文、越南文、阿拉伯文、印地文等)的非拉丁字符的运营商可以在本地语言字符之外还包括拉丁字符的网络名称。对于由NITZ2提供的PLMN名称，运营商可以将网络名称包括在来自非本地语言的非拉丁字符中。

对于由NITZ提供的PLMN名称，如果针对(多个)

字符的语言与UE的MMI的语言不匹配(拉丁文被视为一种语言)，则

UE应该跳过显示

字符。NITZ2优先于NITZ。对于由NITZ2提供的PLMN名称，UE应仅显示以MMI的语言指示的网络名称；在这个过程中，对于这个网络名称，非语言字符或用其他语言编码的字符是[alt1：仍被显示][alt2：被认为是MMI的语言的字符]。如果这会导致PLMN名称中没有剩余的

字母字符，则UE应跳过显示由NITZ2/NITZ提供的PLMN名称；存储在ME中的PLMN名称具有下一个优先级。

附录E-对3GPP TS 22.101的示例更改

A.3国家/PLMN指示

PLMN名称是：

-存储在ME中并与广播信道上接收到的MCC+MNC组合相关联；

-NITZ/NITZ2(参见22.042[17])(在这种情况下，它会覆盖存储在ME中的名称)；

-以文本和/或图形格式存储在USIM中并与MCC+MNC组合以及可选的LAI相关联，在广播信道上被接收(在这种情况下，它会覆盖存储在UE中的名称以及-如果存在的话-NITZ/NITZ2名称)。

对于由NITZ提供的PLMN名称，使用当地语言(如中文、日文、韩文、越南文、阿拉伯文、印地文等)的非拉丁字符的运营商可以在本地语言字符之外还包括拉丁字符的网络名称。对于由NITZ2提供的PLMN名称，运营商可以包括UE的MMI的语言的网络名称。

对于由NITZ提供的PLMN名称，如果针对(多个)

字符的语言与UE的MMI的语言不匹配(拉丁文被认为是一种语言)，则

UE应该跳过显示

字符。NITZ2优先于NITZ。对于由NITZ2提供的PLMN名称，UE应显示所有提供的字符，如MMI的语言所指示(即使是非字母字符或用与MMI不同的语言编码的字符)。如果这会导致针对NITZ/NITZ2的PLMN名称中没有剩余的

字符，则UE应跳过显示由NITZ/NITZ2提供的PLMN名称；存储在ME中的PLMN名称具有下一个优先级。

附录F-对3GPP TS 22.101的示例更改

A.3国家/PLMN指示

PLMN名称是：

-存储在ME中并与广播信道上接收到的MCC+MNC组合相关联；

对于由NITZ提供的PLMN名称，

运营商可以包括

本地语言字符

的网络名称。对于由NITZ2提供的PLMN名称，运营商可以包含UE的MMI的语言的网络名称。由于NITZ2包含MMI的语言的网络名称，所以由NITZ2提供的PLMN名称优先于NITZ(当NITZ2可用时，UE不显示由NITZ提供的网络名称)。对于由NITZ2提供的PLMN名称，UE应显示所有提供的字符，如MMI的语言所指示(即使是非字母字符或具有不同语言代码的字符)。

附录G-3GPP TS 24.QQ8更改示例

10.5.3.5a网络名称

该信息元素的目的是将文本字符串传递给移动台。

网络名称信息元素的编码如图10.5.80/3GPP TS 24.008和表10.5.94/3GPP TS24.008中所示。

如果使用编码方案UCS2并且在文本字符串中接收到ISO/IEC10646[72]中定义的中-日-韩-越南(CJKV)表意文字，则MS应使用它从中接收到网络名称信息元素的PLMN的MCC，来确定用于表10.5.93a/3GPP TS 24.008中指定的那些CJKV表意文字的语言：

表10.5.93a/3GPP TS 24.008：MCC到CJKV表意文字语言映射表

MCC(s)	国家/地区	语言(C,J,K,或V)
			460,461	中国大陆	中文-G
466	中国台湾地区	中文-T
			454	中国香港地区	中文-T
455	中国澳门地区	中文-T
			440,441	日本	J(Kanji)
450,467	韩国	K(Hanja)
			452	越南	V(Chunom)

(…)

a.b.c.d网络名称2

此信息元素的目的是将文本字符串传递给移动台。

网络名称2信息元素的编码如图x1.y2.z1/3GPP TS 24.008和表x2.y2.z2/3GPPTS 24.008中所示。

如果使用编码方案UCS2并且在文本字符串中接收到ISO/IEC10646[72]中定义的中-日-韩-越南(CJKV)表意文字，则MS应使用MMI的语言来确定用于那些CJKV表意文字的语言。

对于3GPP TS 24.008网络名称2信息元素，参见本公开的图8

表10.5.94/3GPP TS 24.008网络名称2信息元素

Claims

1.一种在用户设备处的方法，所述方法包括：

在所述用户设备处接收进行标识的标记字符串，所述字符串还包括指示符位；

基于所述指示符位，执行以下中的一项：

确定所述用户设备是否支持所述标记字符串中的一个或多个标记并且跳过与不支持的标记相对应的字符的显示；或者

显示所述标记字符串内的所有标记。