CN101790140A - 业务请求的发起和处理的方法和设备 - Google Patents
业务请求的发起和处理的方法和设备 Download PDFInfo
- Publication number
- CN101790140A CN101790140A CN200910077584A CN200910077584A CN101790140A CN 101790140 A CN101790140 A CN 101790140A CN 200910077584 A CN200910077584 A CN 200910077584A CN 200910077584 A CN200910077584 A CN 200910077584A CN 101790140 A CN101790140 A CN 101790140A
- Authority
- CN
- China
- Prior art keywords
- request information
- service request
- csfb
- business request
- business
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明提出了一种业务请求的发起和处理方法及设备。所述业务请求的处理方法包括：MME接收第一业务请求消息，并开始执行对第一业务请求消息的处理过程；在MME对第一业务请求消息执行的处理过程没有完成之前，MME接收第二业务请求消息；MME根据第一业务请求消息和第二业务请求消息的类型和/或信息元素执行业务请求处理过程。其中，第一业务请求消息和第二业务请求消息中至少一个包括CSFB业务请求消息。本发明所提出的发起和处理业务请求的方法和设备，提出了对于CSFB业务请求消息某些异常场景的解决方法，以及当寻呼消息与EPS业务请求消息以及CSFB业务请求消息相互之间发生冲突时的解决方法。
Description
技术领域
本发明一般涉及移动通信技术领域，尤其涉及LTE系统中的业务请求过程。
背景技术
在LTE(Long Term Evolution，长期演进)系统中，Service Request(业务请求)过程的目的是当有上行数据或信令要发送时将UE(UserEquipment，用户设备)的EMM(EPS Mobility Management，EPS移动性管理)状态从EMM-IDLE(空闲)态转移到EMM-CONNECTED(连接)状态并建立空口和S1承载。另一个目的是发起MO/MT(Mobile Originated/Mobile Terminated，终端发起/终端终止)的CS fallback(Circuit Switchingfallback，电路交换回退)过程，CS fallback在本发明中或称CSFB。3GPP的协议定义了对于CS fallback引起的Service Request过程，UE发起EXTENDED SERVICE REQUEST(扩展业务请求)消息，而对于其他原因触发的Service Request过程，UE都将发起SERVICE REQUEST消息。
Service Request过程由UE发起，但是，当UE在EMM-IDLE模式下有下行信令或用户数据传输时，这一过程是由网络发起的paging(寻呼)过程触发的。
在以下情况UE必须发起service request过程：
a)UE在EMM-IDLE态时收到paging请求消息；
b)UE在EMM-IDLE状态时有pending(待发的)的用户数据发送；
c)UE在EMM-IDLE状态时有pending的上行信令发送；
d)UE在EMM-IDLE或者EMM-CONNECTED状态时，发起CS fallback请求；
e)UE在EMM-IDLE或者EMM-CONNECTED状态时收到CS fallback的请求；
f)UE在EMM-IDLE状态时有pending的上行cdma
信令。
无论在何种EMM状态，只要UE要发起CS fallback请求，或者UE要发送用于CS fallback寻呼的CS fallback响应，UE都会发起EXTENDEDSERVICE REQUEST消息。
UE发起的EXTENDED SERVICE REQUEST消息的消息格式如表1所示：
表1：EXTENDED SERVICE REQUEST消息内容
| IE | Information Element | Type/Reference | Presence | Format | Length |
| Protocol discriminator | Protocol discriminator9.2 | M | V | 1/2 | |
| Security headertype | Security headertype9.3.1 | M | V | 1/2 | |
| Extended servicerequest messageidentity | Message type9.8 | M | V | 1 | |
| Service type | Service type9.9.3.27 | M | V | 1/2 | |
| NAS key set identifier | NAS key set identifier9.9.3.21 | M | V | 1/2 | |
| M-TMSI | Mobile identity9.9.2.3 | M | LV | 6 | |
| - | CSFB response | CSFB response9.9.3.5 | C | TV | 1 |
其中Service type IE(业务类型信息元素)表示UE发起的EXTENDEDSERVICE REQUEST过程的类型，即是UE主叫CSFB，UE被叫CSFB还是UE主动发起的CSFB emergency call。
CSFB response IE(CSFB响应信息元素)表示UE是否接受CSFB请求。这一IE只有当service type指示为UE被叫CSFB时才会出现。因为当UE收到指示为CS域的寻呼消息时，UE可以判断是否要接受CS业务的请求，UE选择的结果在CSFB response中体现。
对于除了CSFB以外的所有其他原因触发的业务请求过程，UE都发起SERVICE REQUEST消息，SERVICE REQUEST消息中不包含任何业务类型的指示。
MME发送给eNB(Evolved NodeB，演进基站)的寻呼消息中会用CNdomain IE来指示是来自于一个PS(Packet Switching，分组交换)域的寻呼消息还是一个CS(Circuit Switching，电路交换)域的寻呼消息。若UE收到指示为PS域的paging，则返回SERVICE REQUEST消息给MME；若UE收到指示为CS域的paging，则返回EXTENDED SERVICE REQUEST消息。Service Request过程，对于UE被叫的处理过程与UE主叫的处理过程相同。
MME收到SERVICE REQUEST消息后统一发起S 1的初始上下文建立过程，要求为所有在MME中处于激活态的EPS(Evolved Packet System，演进分组系统)承载建立S1和空口的承载连接。当承载建立完成后，UE或者MME就可以发送相应的信令或者数据。
对于处于EMM-IDLE态的UE若发起的EXTENDED SERVICEREQUEST消息到达MME后，第一步MME同样需要发起初始上下文建立过程，为所有在MME中处于激活态的EPS承载建立S1和空口的承载连接，这一部分的操作与正常收到SERVICE REQUEST消息相同。承载建立完成后，还需要执行第二步，eNB还需要发起将UE从SAE(System ArchitectureEvolution，系统架构演进)系统转移到CS业务所在的GERAN(GSM/EDGERadio Access Network，GSM/EDGE无线接入网)或者UTRAN(UniversalTerrestrial Radio Access Network，通用陆地无线接入网)系统的操作，即发起PS HO切换(PS Handover，PS切换)，或者是NACC(Network AssistedCell Change，网络辅助小区重选)过程。如果处于EMM-CONNECTED状态的UE发起了EXTENDED SERVICE REQUEST消息，MME则不需要执行第一步，初始上下文的建立过程，直接执行第二步，eNB发起PS切换到CS业务所在的PS系统或者执行NACC过程。
现有协议只对EPS业务的Service Request过程异常处理进行了描述，而对于CSFB的Service Request过程异常处理，以及对于EPS业务的ServiceRequest过程和CSFB的Service Request过程之间的冲突处理也没有描述。因此，需要一种针对CSFB的Service Request过程异常处理，以及EPS业务的Service Request过程和CSFB的Service Request过程之间出现冲突时的处理方法。
发明内容
为了解决上述问题之一，本发明提出了一种处理业务请求的方法，包括以下步骤：A、移动性管理实体MME接收第一业务请求消息，并开始执行对所述第一业务请求消息的处理过程；B、在所述MME对所述第一业务请求消息执行的处理过程没有完成之前，所述MME接收第二业务请求消息；C、所述MME根据所述第一业务请求消息和第二业务请求消息的类型和/或信息元素执行业务请求处理过程。其中，所述第一业务请求消息和所述第二业务请求消息中至少一个包括电路交换回退CSFB业务请求消息。
根据本发明的实施例，所述第一业务请求消息和所述第二业务请求消息都为CSFB业务请求消息。所述步骤C包括：所述MME根据所述第一业务请求消息和所述第二业务请求消息中的信息元素执行业务请求处理过程。
根据本发明的实施例，所述步骤C包括：如果所述第二业务请求消息中有至少一个信息元素与所述第一业务请求消息不同，则所述MME取消对所述第一业务请求消息的处理过程，执行对所述第二业务请求消息的处理过程；如果所述第二业务请求消息中的信息元素与所述第一业务请求消息全部相同，则所述MME继续执行对所述第一业务请求消息的处理过程，对所述第二业务请求消息不做处理。
根据本发明的实施例，所述第一业务请求消息为CSFB业务请求消息，所述第二业务请求消息为演进分组系统EPS业务请求消息。所述步骤C包括：所述MME继续执行对所述第一业务请求消息的处理过程，对所述第二业务请求消息不做处理。
根据本发明的实施例，所述第一业务请求消息为EPS业务请求消息，所述第二业务请求消息为CSFB业务请求消息。所述步骤C包括：所述MME终止执行对所述第一业务请求消息的处理过程，执行对所述第二业务请求消息的处理过程。
本发明还提出了一种MME，包括接收模块和处理模块。所述接收模块，用于接收第一业务请求消息，以及在所述处理模块对所述第一业务请求消息执行的处理过程没有完成之前，接收第二业务请求消息。所述处理模块，用于在所述接收模块接收所述第一业务请求消息之后，开始执行对所述第一业务请求消息的处理过程，以及在所述接收模块接收所述第二业务请求消息之后，根据所述第一业务请求消息和第二业务请求消息的类型和/或信息元素执行业务请求处理过程。其中，所述第一业务请求消息和所述第二业务请求消息中至少一个包括电路交换回退CSFB业务请求消息。
根据本发明的实施例，所述处理模块包括第一处理模块，其用于在所述第一业务请求消息和所述第二业务请求消息都为CSFB业务请求消息时，根据所述第一业务请求消息和所述第二业务请求消息中的信息元素执行业务请求处理过程。
根据本发明的实施例，所述第一处理模块还用于在所述第二业务请求消息中有至少一个信息元素与所述第一业务请求消息不同时，取消对所述第一业务请求消息的处理过程，执行对所述第二业务请求消息的处理过程；以及在所述第二业务请求消息中的信息元素与所述第一业务请求消息全部相同时，继续执行对所述第一业务请求消息的处理过程，对所述第二业务请求消息不做处理。
根据本发明的实施例，所述处理模块还包括第二处理模块，其用于在所述第一业务请求消息为CSFB业务请求消息，所述第二业务请求消息为演进分组系统EPS业务请求消息时，继续执行对所述第一业务请求消息的处理过程，对所述第二业务请求消息不做处理。
根据本发明的实施例，所述处理模块还包括第三处理模块，其用于在所述第一业务请求消息为EPS业务请求消息，所述第二业务请求消息为CSFB业务请求消息时，终止执行对所述第一业务请求消息的处理过程，执行对所述第二业务请求消息的处理过程。
本发明还提出了一种发起业务请求的方法，包括：用户设备UE根据待发的业务请求的类型、接收的电路交换CS域寻呼消息和/或所述UE所处的状态，执行业务请求过程。其中所述待发的业务请求的类型包括演进分组系统EPS业务请求和/或电路交换回退CSFB业务请求。
根据本发明的实施例，所述UE根据待发的业务请求的类型、接收的电路交换CS域寻呼消息和/或所述UE所处的状态执行业务请求过程的步骤包括：如果所述UE在空闲IDLE状态接收到所述CS域寻呼消息，并有待发的CSFB业务请求，则所述UE忽略所述CS域寻呼消息，执行对应于所述待发的CSFB业务请求的CSFB业务请求过程。
根据本发明的实施例，所述UE根据待发的业务请求的类型、接收的电路交换CS域寻呼消息和/或所述UE所处的状态执行业务请求过程的步骤包括：如果所述UE在IDLE状态接收到所述CS域寻呼消息，并具有待发的EPS业务请求，则所述UE执行对应于所述CS域寻呼消息的CSFB业务请求过程。
根据本发明的实施例，所述UE根据待发的业务请求的类型、接收的电路交换CS域寻呼消息和/或所述UE所处的状态执行业务请求过程的步骤包括：如果所述UE在IDLE状态接收到所述CS域寻呼消息，并具有待发的EPS业务请求，则所述UE判断是否接受CSFB请求，并在判断接受所述CSFB请求后，执行对应于所述CS域寻呼消息的CSFB业务请求过程。
根据本发明的实施例，所述UE根据待发的业务请求的类型、接收的电路交换CS域寻呼消息和/或所述UE所处的状态执行业务请求过程的步骤包括：如果所述UE既有待发的EPS的业务请求也有待发的CSFB请求，则所述UE执行对应于所述待发的CSFB请求的CSFB业务请求过程。
本发明还提出了一种用户设备UE，包括：发送模块，其用于根据待发的业务请求的类型、接收的电路交换CS域寻呼消息和/或所述UE所处的状态，执行业务请求过程。其中所述待发的业务请求的类型包括演进分组系统EPS业务请求和/或电路交换回退CSFB业务请求。
根据本发明的实施例，所述UE还包括接收模块，用于接收所述CS域寻呼消息。所述发送模块包括第一发送模块，其用于在所述UE处于空闲IDLE状态、所述接收模块接收到所述CS域寻呼消息、并有待发的CSFB业务请求时，忽略所述CS域寻呼消息，执行对应于所述待发的CSFB业务请求的CSFB业务请求过程。
根据本发明的实施例，所述CSFB业务请求过程中的CSFB业务请求消息的业务类型信息元素为UE主动发起的CSFB过程。
根据本发明的实施例，所述UE还包括接收模块，用于接收所述CS域寻呼消息。所述发送模块包括第二发送模块，其用于在所述UE处于IDLE状态、所述接收模块接收到所述CS域寻呼消息、并具有待发的EPS业务请求时，执行对应于所述CS域寻呼消息的CSFB业务请求过程。
根据本发明的实施例，所述UE还包括接收模块，用于接收所述CS域寻呼消息。所述发送模块包括第三发送模块，其用于在所述UE在IDLE状态、所述接收模块接收到所述CS域寻呼消息、并具有待发的EPS业务请求时，判断是否接受CSFB请求，并在判断接受所述CSFB请求后，执行对应于所述CS域寻呼消息的CSFB业务请求过程。
根据本发明的实施例，所述CSFB业务请求过程中的CSFB业务请求消息的业务类型信息元素为UE被叫的CSFB过程。
根据本发明的实施例，所述发送模块包括第四发送模块，其用于在既有待发的EPS的业务请求也有待发的CSFB请求时，执行对应于所述待发的CSFB请求的CSFB业务请求过程。
本发明所提出的发起和处理业务请求的方法和设备，提出了对于CSFB业务请求消息的某些异常场景的解决方法，以及当寻呼消息与EPS业务请求消息以及CSFB业务请求消息相互之间发生冲突时的解决方法，易于在现有的系统和协议的基础上实现。
附图说明
本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为本发明的业务请求处理方法的一个实施例的流程图；
图2为本发明的MME的一个实施例的功能结构图；
图3为本发明的UE的一个实施例的功能结构图。
具体实施方式
下面详细描述本发明的实施例，所述实施例的示例在附图中示出。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。
另外，本发明中提到的“第一”、“第二”等仅仅为了便于描述，而不应解释为对本发明的限制。
本发明的一个实施例提出了一种处理业务请求的方法100，如图1所示，包括以下步骤：
S101：MME接收第一业务请求消息，并开始执行对第一业务请求消息的处理过程；
S102：在MME对第一业务请求消息执行的处理过程没有完成之前，MME接收第二业务请求消息；
S103：MME根据第一业务请求消息和第二业务请求消息的类型和/或信息元素执行业务请求处理过程。
其中，第一业务请求消息和第二业务请求消息中至少一个包括CSFB业务请求消息。
作为本发明的实施例，CSFB业务请求消息可以包括EXTENDEDSERVICE REQUEST消息，EPS业务请求消息可以包括SERVICEREQUEST消息。在下文中，以EXTENDED SERVICE REQUEST消息和SERVICE REQUEST消息作为示例进行说明，但是这仅仅是一个示例，而不应解释为对本发明的限制。在具体实施过程中根据需要也可以定义其他的业务消息类型。
下面对于方法100在不同的场景下的具体实施方式分别进行描述：
如果第一业务请求消息和第二请求消息都是EXTENDED SERVICEREQUEST消息。即，MME收到了一个EXTENDED SERVICE REQUEST消息，并且在对该EXTENDED SERVICE REQUEST消息的处理过程还没完成之前又收到了EXTENDED SERVICE REQUEST消息，那么步骤S103包括：
若后续收到的EXTENDED SERVICE REQUEST消息中有一个IE与之前的EXTENDED SERVICE REQUEST消息不同，则MME取消之前的Service Request过程而执行新的Service Request过程；
若后续收到的EXTENDED SERVICE REQUEST消息与之前的SERVICE REQUEST消息中的所有IE都相同，则MME继续执行之前的Service Request过程，对于后续收到的EXTENDED SERVICE REQUEST消息不做处理。
如果第一业务请求消息为EXTENDED SERVICE REQUEST消息，第二业务请求消息为SERVICE REQUEST消息。即，MME收到了一个EXTENDED SERVICE REQUEST消息，并且在对该EXTENDED SERVICEREQUEST消息的处理过程还没完成之前又收到了SERVICE REQUEST消息，则步骤S103包括：MME继续执行之前的EXTENDED SERVICEREQUEST消息的处理过程，对后续的SERVICE REQUEST消息不做处理。
如果第一业务请求消息为SERVICE REQUEST消息，第二业务请求消息为EXTENDED SERVICE REQUEST消息。即，MME收到了一个SERVICE REQUEST消息，并且在对该SERVICE REQUEST消息的处理过程还没完成之前又收到了EXTENDED SERVICE REQUEST消息。则步骤S103包括：MME终止现有的SERVICE REQUEST消息的处理过程，执行新收到的EXTENDED SERVICE REQUEST消息的处理过程。
本发明的一个实施例提出了一种发起业务请求的方法，包括：UE根据待发的业务请求的类型、接收的电路交换CS域寻呼消息和/或所述UE所处的状态，发送业务请求消息。其中待发的业务请求的类型包括演进分组系统EPS业务请求和/或电路交换回退CSFB业务请求。
下面对于所述发起业务请求的方法在不同的场景下的具体实施方式进行描述：
如果UE在IDLE状态收到了指示为CS域的寻呼消息，而此时UE处正好有pending的CSFB请求，则UE忽略收到的paging消息，而执行由上行pending的CSFB请求所触发的EXTENDED SERVICE REQUEST消息。作为本发明的实施例，将这一消息中的Service type IE设置为UE主动发起的CSFB过程。
如果UE在IDLE状态收到了指示为CS域的寻呼消息，而此时UE处正好有pending的PS业务请求，则UE继续执行收到paging消息的后续过程，直接返回EXTENDED SERVICE REQUEST消息，或者UE判断是否接受CSFB请求，并在判断接受CSFB请求后返回EXTENDED SERVICEREQUEST消息，而不发起对应于pending的PS业务请求的SERVICEREQUEST消息。作为本发明的实施例，在EXTENDED SERVICE REQUEST消息中将Service type IE设置为UE被叫的CSFB过程。
如果UE处既有上行的PS的业务请求也有上行的CSFB的请求，UE将触发EXTENDED SERVICE REQUEST消息执行CSFB的业务请求过程。
本发明的一个实施例提出了一种MME 200，如图2所示，MME 200包括接收模块201和处理模块202，其中：接收模块201接收第一业务请求消息，以及在处理模块202对第一业务请求消息执行的处理过程没有完成之前，接收第二业务请求消息。处理模块202在接收模块201接收第一业务请求消息之后，开始执行对第一业务请求消息的处理过程，以及在接收模块201接收第二业务请求消息之后，根据第一业务请求消息和第二业务请求消息的类型和/或信息元素执行业务请求处理过程。其中，第一业务请求消息和所述第二业务请求消息中至少一个包括CSFB业务请求消息。
作为本发明的实施例，处理模块202包括第一处理模块2021。第一处理模块2021在第一业务请求消息和第二业务请求消息都为CSFB业务请求消息时，根据第一业务请求消息和第二业务请求消息中的信息元素执行业务请求处理过程。例如，第一处理模块2021在第二业务请求消息中有至少一个信息元素与第一业务请求消息不同时，取消对第一业务请求消息的处理过程，执行对第二业务请求消息的处理过程；在第二业务请求消息中的信息元素与第一业务请求消息全部相同时，继续执行对第一业务请求消息的处理过程，对第二业务请求消息不做处理。
作为本发明的实施例，处理模块202包括第二处理模块2022。第二处理模块2022在第一业务请求消息为CSFB业务请求消息，第二业务请求消息为EPS业务请求消息时，继续执行对第一业务请求消息的处理过程，对第二业务请求消息不做处理。
作为本发明的实施例，处理模块202还包括第三处理模块2023。第三处理模块2023在第一业务请求消息为EPS业务请求消息，第二业务请求消息为CSFB业务请求消息时，终止执行对第一业务请求消息的处理过程，执行对第二业务请求消息的处理过程。
本发明的一个实施例提出了一种UE 300，如图3所示，UE 300包括发送模块301。发送模块301根据待发的业务请求的类型、接收的电路交换CS域寻呼消息和/或UE 300所处的状态，执行业务请求过程，例如，发送业务请求消息。其中待发的业务请求的类型包括EPS业务请求和/或CSFB业务请求。
作为本发明的实施例，UE300还包括接收模块302，其接收CS域寻呼消息。
作为本发明的实施例，发送模块301包括第一发送模块3011，其用于在UE 300处于空闲IDLE状态、接收模块302接收到CS域寻呼消息、并有待发的CSFB业务请求时，忽略CS域寻呼消息，执行对应于待发的CSFB业务请求的CSFB业务请求过程。作为本发明的实施例，发送模块3011可以发送EXTENDED SERVICE REQUEST消息，在该实施例中，EXTENDEDSERVICE REQUEST消息中的业务类型信息元素为UE主动发起的CSFB过程。
作为本发明的实施例，发送模块301包括第二发送模块3012，其用于在UE 300处于IDLE状态、接收模块302接收到CS域寻呼消息、并具有待发的EPS业务请求时，执行对应于CS域寻呼消息的CSFB业务请求过程。作为本发明的实施例，发送模块3012可以发送EXTENDED SERVICEREQUEST消息，在该实施例中，EXTENDED SERVICE REQUEST消息中的业务类型信息元素为UE被叫的CSFB过程。
作为本发明的实施例，发送模块301包括第三发送模块3013，其用于在UE 300在IDLE状态、接收模块302接收到CS域寻呼消息、并具有待发的EPS业务请求时，判断是否接受CSFB请求，并在判断接受CSFB请求后，执行对应于CS域寻呼消息的CSFB业务请求消息。作为本发明的实施例，发送模块3013可以发送EXTENDED SERVICE REQUEST消息，在该实施例中，EXTENDED SERVICE REQUEST消息中的业务类型信息元素为UE被叫的CSFB过程。
作为本发明的实施例，发送模块301包括第四发送模块3014，其用于在既有待发的EPS的业务请求也有待发的CSFB请求时，执行对应于待发的CSFB请求的CSFB业务请求过程，作为本发明的实施例，发送模块3014可以发送EXTENDED SERVICE REQUEST消息。
本发明所提出的发起和处理业务请求的方法和设备，提出了对于CSFB业务请求消息的某些异常场景的解决方法，以及当寻呼消息与EPS业务请求消息以及CSFB业务请求消息相互之间发生冲突时的解决方法，易于在现有的系统和协议的基础上实现。
尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同限定。
Claims (24)
1.一种处理业务请求的方法，其特征在于，包括以下步骤：
A、移动性管理实体MME接收第一业务请求消息，并开始执行对所述第一业务请求消息的处理过程；
B、在所述MME对所述第一业务请求消息执行的处理过程没有完成之前，所述MME接收第二业务请求消息；
C、所述MME根据所述第一业务请求消息和第二业务请求消息的类型和/或信息元素执行业务请求处理过程，
其中，所述第一业务请求消息和所述第二业务请求消息中至少一个包括电路交换回退CSFB业务请求消息。
2.根据权利要求1所述的处理业务请求的方法，其特征在于，
所述第一业务请求消息和所述第二业务请求消息都为CSFB业务请求消息，
所述步骤C包括：
所述MME根据所述第一业务请求消息和所述第二业务请求消息中的信息元素执行业务请求处理过程。
3.根据权利要求2所述的处理业务请求的方法，其特征在于，
所述步骤C包括：
如果所述第二业务请求消息中有至少一个信息元素与所述第一业务请求消息不同，则所述MME取消对所述第一业务请求消息的处理过程，执行对所述第二业务请求消息的处理过程；
如果所述第二业务请求消息中的信息元素与所述第一业务请求消息全部相同，则所述MME继续执行对所述第一业务请求消息的处理过程，对所述第二业务请求消息不做处理。
4.根据权利要求1所述的处理业务请求的方法，其特征在于，
所述第一业务请求消息为CSFB业务请求消息，所述第二业务请求消息为演进分组系统EPS业务请求消息，
所述步骤C包括：
所述MME继续执行对所述第一业务请求消息的处理过程，对所述第二业务请求消息不做处理。
5.根据权利要求1所述的处理业务请求的方法，其特征在于，
所述第一业务请求消息为EPS业务请求消息，所述第二业务请求消息为CSFB业务请求消息，
所述步骤C包括：
所述MME终止执行对所述第一业务请求消息的处理过程，执行对所述第二业务请求消息的处理过程。
6.一种MME，其特征在于，包括接收模块和处理模块，其中：
所述接收模块，用于接收第一业务请求消息，以及在所述处理模块对所述第一业务请求消息执行的处理过程没有完成之前，接收第二业务请求消息；
所述处理模块，用于在所述接收模块接收所述第一业务请求消息之后，开始执行对所述第一业务请求消息的处理过程，以及在所述接收模块接收所述第二业务请求消息之后，根据所述第一业务请求消息和第二业务请求消息的类型和/或信息元素执行业务请求处理过程，
其中，所述第一业务请求消息和所述第二业务请求消息中至少一个包括电路交换回退CSFB业务请求消息。
7.根据权利要求6所述的MME，其特征在于，
所述处理模块包括第一处理模块，其用于在所述第一业务请求消息和所述第二业务请求消息都为CSFB业务请求消息时，根据所述第一业务请求消息和所述第二业务请求消息中的信息元素执行业务请求处理过程。
8.根据权利要求7所述的MME，其特征在于，
所述第一处理模块还用于在所述第二业务请求消息中有至少一个信息元素与所述第一业务请求消息不同时，取消对所述第一业务请求消息的处理过程，执行对所述第二业务请求消息的处理过程；以及
在所述第二业务请求消息中的信息元素与所述第一业务请求消息全部相同时，继续执行对所述第一业务请求消息的处理过程，对所述第二业务请求消息不做处理。
9.根据权利要求6所述的MME，其特征在于，
所述处理模块还包括第二处理模块，其用于在所述第一业务请求消息为CSFB业务请求消息，所述第二业务请求消息为演进分组系统EPS业务请求消息时，继续执行对所述第一业务请求消息的处理过程，对所述第二业务请求消息不做处理。
10.根据权利要求6所述的MME，其特征在于，
所述处理模块还包括第三处理模块，其用于在所述第一业务请求消息为EPS业务请求消息，所述第二业务请求消息为CSFB业务请求消息时，终止执行对所述第一业务请求消息的处理过程，执行对所述第二业务请求消息的处理过程。
11.一种发起业务请求的方法，其特征在于，包括：
用户设备UE根据待发的业务请求的类型、接收的电路交换CS域寻呼消息和/或所述UE所处的状态，执行业务请求过程，
其中所述待发的业务请求的类型包括演进分组系统EPS业务请求和/或电路交换回退CSFB业务请求。
12.根据权利要求11所述的发起业务请求的方法，其特征在于，所述UE根据待发的业务请求的类型、接收的电路交换CS域寻呼消息和/或所述UE所处的状态执行业务请求过程的步骤包括：
如果所述UE在空闲IDLE状态接收到所述CS域寻呼消息，并有待发的CSFB业务请求，则所述UE忽略所述CS域寻呼消息，执行对应于所述待发的CSFB业务请求的CSFB业务请求过程。
13.根据权利要求12所述的发起业务请求的方法，其特征在于，所述UE将所述CSFB业务请求过程中的CSFB业务请求消息的业务类型信息元素设置为UE主动发起的CSFB过程。
14.根据权利要求11所述的发起业务请求的方法，其特征在于，所述UE根据待发的业务请求的类型、接收的电路交换CS域寻呼消息和/或所述UE所处的状态执行业务请求过程的步骤包括：
如果所述UE在IDLE状态接收到所述CS域寻呼消息，并具有待发的EPS业务请求，则所述UE执行对应于所述CS域寻呼消息的CSFB业务请求过程。
15.根据权利要求11所述的发起业务请求的方法，其特征在于，所述UE根据待发的业务请求的类型、接收的电路交换CS域寻呼消息和/或所述UE所处的状态执行业务请求过程的步骤包括：
如果所述UE在IDLE状态接收到所述CS域寻呼消息，并具有待发的EPS业务请求，则所述UE判断是否接受CSFB请求，并在判断接受所述CSFB请求后，执行对应于所述CS域寻呼消息的CSFB业务请求过程。
16.根据权利要求14或15所述的发起业务请求的方法，其特征在于，
所述UE将所述CSFB业务请求过程中的CSFB业务请求消息的业务类型信息元素设置为UE被叫的CSFB过程。
17.根据权利要求11所述的发起业务请求的方法，其特征在于，所述UE根据待发的业务请求的类型、接收的电路交换CS域寻呼消息和/或所述UE所处的状态执行业务请求过程的步骤包括：
如果所述UE既有待发的EPS的业务请求也有待发的CSFB请求，则所述UE执行对应于所述待发的CSFB请求的CSFB业务请求过程。
18.一种用户设备UE，其特征在于，包括：
发送模块，其用于根据待发的业务请求的类型、接收的电路交换CS域寻呼消息和/或所述UE所处的状态，执行业务请求过程，
其中所述待发的业务请求的类型包括演进分组系统EPS业务请求和/或电路交换回退CSFB业务请求。
19.根据权利要求18所述的UE，其特征在于，所述UE还包括接收模块，用于接收所述CS域寻呼消息，
所述发送模块包括第一发送模块，其用于在所述UE处于空闲IDLE状态、所述接收模块接收到所述CS域寻呼消息、并有待发的CSFB业务请求时，忽略所述CS域寻呼消息，执行对应于所述待发的CSFB业务请求的CSFB业务请求过程。
20.根据权利要求19所述的UE，其特征在于，所述CSFB业务请求过程中的CSFB业务请求消息的业务类型信息元素为UE主动发起的CSFB过程。
21.根据权利要求18所述的UE，其特征在于，所述UE还包括接收模块，用于接收所述CS域寻呼消息，
所述发送模块包括第二发送模块，其用于在所述UE处于IDLE状态、所述接收模块接收到所述CS域寻呼消息、并具有待发的EPS业务请求时，执行对应于所述CS域寻呼消息的CSFB业务请求过程。
22.根据权利要求18所述的UE，其特征在于，所述UE还包括接收模块，用于接收所述CS域寻呼消息，
所述发送模块包括第三发送模块，其用于在所述UE在IDLE状态、所述接收模块接收到所述CS域寻呼消息、并具有待发的EPS业务请求时，判断是否接受CSFB请求，并在判断接受所述CSFB请求后，执行对应于所述CS域寻呼消息的CSFB业务请求过程。
23.根据权利要求21或22所述的UE，其特征在于，
所述CSFB业务请求过程中的CSFB业务请求消息的业务类型信息元素为UE被叫的CSFB过程。
24.根据权利要求18所述的UE，其特征在于，所述发送模块包括第四发送模块，其用于在既有待发的EPS的业务请求也有待发的CSFB请求时，执行对应于所述待发的CSFB请求的CSFB业务请求过程。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910077584A CN101790140A (zh) | 2009-01-23 | 2009-01-23 | 业务请求的发起和处理的方法和设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910077584A CN101790140A (zh) | 2009-01-23 | 2009-01-23 | 业务请求的发起和处理的方法和设备 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101790140A true CN101790140A (zh) | 2010-07-28 |
Family
ID=42533143
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200910077584A Pending CN101790140A (zh) | 2009-01-23 | 2009-01-23 | 业务请求的发起和处理的方法和设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101790140A (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2012051953A1 (zh) * | 2010-10-20 | 2012-04-26 | 电信科学技术研究院 | 一种业务请求的处理方法和设备 |
| CN106714255A (zh) * | 2016-12-20 | 2017-05-24 | 北京小米移动软件有限公司 | 语音呼叫处理方法、装置及终端 |
| EP4274371A1 (en) * | 2022-05-05 | 2023-11-08 | Shenzhen Xiaomi Communication Technology Co., Ltd. | Call response method and device |
-
2009
- 2009-01-23 CN CN200910077584A patent/CN101790140A/zh active Pending
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2012051953A1 (zh) * | 2010-10-20 | 2012-04-26 | 电信科学技术研究院 | 一种业务请求的处理方法和设备 |
| CN102457976A (zh) * | 2010-10-20 | 2012-05-16 | 电信科学技术研究院 | 一种业务请求的处理方法和设备 |
| CN102457976B (zh) * | 2010-10-20 | 2014-07-16 | 电信科学技术研究院 | 一种业务请求的处理方法和设备 |
| CN106714255A (zh) * | 2016-12-20 | 2017-05-24 | 北京小米移动软件有限公司 | 语音呼叫处理方法、装置及终端 |
| CN106714255B (zh) * | 2016-12-20 | 2020-03-03 | 北京小米移动软件有限公司 | 语音呼叫处理方法、装置及终端 |
| EP4274371A1 (en) * | 2022-05-05 | 2023-11-08 | Shenzhen Xiaomi Communication Technology Co., Ltd. | Call response method and device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11115893B2 (en) | Information transmission method, base station, and user equipment | |
| US8849319B2 (en) | Method for processing conflict of communication service procedures and associated devices | |
| KR101339044B1 (ko) | 서빙 코어 네트워크 노드가 변경될 때의 모바일 장치의 접근성의 처리 | |
| AU2015218697B2 (en) | Circuit switched fallback | |
| EP2291014B1 (en) | Method and corresponding terminal for association relationship updating | |
| EP3193528B1 (en) | Method and device for detaching user equipment | |
| JP6587016B2 (ja) | 移動通信デバイス及び通信制御方法 | |
| WO2019076273A1 (zh) | 一种切换的方法、移动性管理网元和通信系统 | |
| CN101572943B (zh) | Mme释放isr情况下空闲态ue上下文的方法、装置及系统 | |
| CN114631367A (zh) | 向musim用户设备提供寻呼原因的方法和系统 | |
| CN101483823B (zh) | 位置更新及其请求的方法、设备和进行接入的方法、设备 | |
| CN101448287B (zh) | 一种激活状态下用户设备跨接入网切换的实现方法 | |
| US20130183968A1 (en) | Method For Mobility Management In A System Architecture Supporting Mobility Between Different Access Systems | |
| EP2974486B1 (en) | Method and apparatus for paging terminated call in mobile communication system | |
| CN103607783A (zh) | 一种csfb呼叫建立方法及用户设备 | |
| CN105210421A (zh) | 用于在多载波系统中操作终端的方法 | |
| EP2822308A1 (en) | Service processing method and device in communication network | |
| US20150201397A1 (en) | Apparatus and method for paging in wireless communication system | |
| CN101394340A (zh) | 数据传输方法、系统和装置 | |
| EP2540115B1 (en) | Mobile terminated control method and mobile terminal device | |
| US9433000B2 (en) | Single-card dual-standby terminal and data service connecting method | |
| CN101790140A (zh) | 业务请求的发起和处理的方法和设备 | |
| KR102076985B1 (ko) | 차세대 이동통신 시스템에서의 긴급 메시지 전송 방법 및 장치 | |
| CN102651902A (zh) | 非接入层（nas）不能传输指示的处理方法及基站、mme 设备 | |
| KR102023421B1 (ko) | 이동 단말 위치 정보를 이용한 ptt 서비스 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| ASS | Succession or assignment of patent right |
Owner name: INST OF TELECOMMUNICATION SCIENCE AND TECHNOLGOY Free format text: FORMER OWNER: DATANG MOBILE COMMUNICATION EQUIPMENT CO., LTD. Effective date: 20110408 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| COR | Change of bibliographic data |
Free format text: CORRECT: ADDRESS; FROM: 100083 NO. 29, XUEYUAN ROAD, HAIDIAN DISTRICT, BEIJING TO: 100191 NO. 40, XUEYUAN ROAD, HAIDIAN DISTRICT, BEIJING |
|
| TA01 | Transfer of patent application right |
Effective date of registration: 20110408 Address after: 100191 Haidian District, Xueyuan Road, No. 40, Applicant after: Inst of Telecommunication Science and Technolgoy Address before: 100083 Haidian District, Xueyuan Road, No. 29, Applicant before: Datang Mobile Communication Equipment Co., Ltd. |
|
| C12 | Rejection of a patent application after its publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20100728 |